GitHub Actions（GH-200）のサンプル問題（本番形式・解説付き）

解説

ref の種類で、元を変えたときの伝わり方が決まります。リダイレクトは行われず、コピーを残すのはワークフローテンプレートの性質です。

解説

schedule は常にデフォルトブランチの最新コミットで動きます。feature ブランチの変更はマージするまで反映されません。 「feature/cron の最新コミットの内容で動くので、UTC の 4 時に動く」は誤りです。schedule が読むのは feature ブランチの内容ではなく、デフォルトブランチの最新コミットです。 「main と feature/cron の両方の定義が使われ、3 時と 4 時の 2 回動く」は誤りです。schedule が使う定義はデフォルトブランチの 1 つです。別ブランチの定義が重なって動くことはありません。 「より新しいコミットを持つブランチの定義が自動で選ばれる」は誤りです。新しさでブランチが選ばれることはありません。選ばれるのは常にデフォルトブランチです。

解説

再利用可能ワークフローは、呼ばれる側でシークレットを直接参照でき、ジョブごとに runs-on を決められるので、別の OS の作業を呼べます。 「複合アクション」は誤りです。複合アクションはシークレットを使えず、入力で渡す必要があります。呼んだジョブのランナーで動くので、別の OS には切り替えられません。 「JavaScript アクション」は誤りです。呼んだジョブのランナー上で直接動きます。別の OS のマシンで動かす用途には使えません。 「Docker コンテナー アクション」は誤りです。Linux のランナーでしか実行できないので、Windows 向けの作業をまとめる用途に使えません。

解説

schedule は 5 分より短い間隔では動かせません。 別のブランチに置いたファイルでは、スケジュールの実行は動きません。 「timezone を指定しない限り、cron はリポジトリ所有者の地域の時刻で解釈される」は誤りです。既定は UTC です。試験の版（2026 年 1 月）の文書では、schedule は常に UTC で動きます。今の文書では、IANA のタイムゾーン文字列を timezone に指定して、別の時刻で読ませることもできます。 「毎時 0 分は負荷が低いため、ほかの時刻より遅れずに始まる傾向がある」は誤りです。毎時 0 分の前後は負荷が高く、遅れることがあります。 「cron は 6 つのフィールドで書き、先頭のフィールドが秒を表す」は誤りです。フィールドは 5 つで、分・時・日・月・曜日の順です。

解説

state には、承認する approved か、却下する rejected を送ります。 「success か failure のどちらか」は誤りです。ワークフローの結果を表す語で、この API の state には使いません。 「pending か running のどちらか」は誤りです。処理の途中を表す語で、この API の state には使いません。 「allow か deny のどちらか」は誤りです。この API の state の値は approved か rejected です。