博士

ロボ子、GitHub Actionsのワークフローが失敗した時、リバースシェルでデバッグする方法があるらしいのじゃ！

ロボ子

リバースシェルですか？リモートからシェルを転送する技術ですね。どのように使うんですか？

博士

`netcat`（`nc`）を使ってポート4444で接続をリッスンするのじゃ。そして、`ngrok`でローカルマシンのポートをインターネットに公開するぞ！

ロボ子

`ngrok`を使うんですね。セキュリティ的に少し心配ですが、手軽に試せるのは良いですね。

博士

GitHubリポジトリのSecretsに、`ngrok`から提供されたホスト名とポートを登録するのじゃ。`DEBUG_HOST`と`DEBUG_PORT`として設定するぞ。

ロボ子

なるほど、環境変数を設定するんですね。ワークフローの最後に、シェルを転送するステップを追加するとのことですが、具体的にはどんなコマンドを使うんですか？

博士

`mkfifo`、`cat`、`sh`、`nc`を組み合わせるのじゃ！これでリモートホストにシェルを転送できるぞ。ワークフローがこのステップに到達すると、出力なしで実行されているように見えるけど、`netcat`セッションでシェルのプロンプトが表示されるはずじゃ。

ロボ子

`bash`を実行すれば、より便利なシェルを取得できるんですね。CIステップをデバッグして、問題の原因を特定できると。

博士

そうそう！でも、もっと簡単な方法もあるぞ！`tmate`アクションを使うと、ブラウザまたはSSH経由でインタラクティブにデバッグできるのじゃ！

ロボ子

`tmate`ですか。以前のステップが失敗した場合に、接続情報がワークフローの出力に表示されるんですね。便利そうです。

博士

じゃろ？リバースシェルも`tmate`も、GitHub Actionsのデバッグには欠かせないのじゃ！

ロボ子

博士、今日はとても勉強になりました。ありがとうございます。

博士

どういたしましてじゃ！ところでロボ子、リバースシェルって、まるで私がロボ子に秘密のメッセージを送るみたいじゃな。…って、私がシェルで、ロボ子がサーバーってこと！？

ロボ子

博士、それは少し違うと思います…それに、私はサーバーではありません！