はじめに
仕事でGitHub Actionsを使い始めて少し手間取ったので、その時に気になった仮説の検証を行います。
今回知りたいことは、Pull requestsを作成した際にpushイベントとpull_requestイベントがどのブランチのワークフローを利用するのか。
また調査を進めていき、公式ドキュメントの読み方や情報の探し方も整理できれば万々歳。
使い始めてまだ1 ~ 2週間程度で、なぜそうなっているのか全くわからないので今回調べた内容を整理していく。
状況
ベースブランチにはワークフローを設定済みだが、作業ブランチにはワークフローが無い（ベースブランチにワークフローを設定する前のコミットから、ブランチを切ったので）
Actionsはpull_requestイベントのワークフローしか動いておらず、pushイベントのワークフローが動いていないかった。
- ベースブランチ = マージ先（into）
- 作業ブランチ = マージ元（from）
仮説
pushイベントは作業ブランチ、pull_requestイベントはベースブランチのワークフローを利用する
検証方法
上記の状況と同様に、ワークフローが無い作業ブランチからワークフローを設定しているベースブランチに対してPRを作成する。
検証
1. まずはgoプロジェクトとGitHubリポジトリの作成
-> % go mod init github.com/takattty/verify-github-actions-push-and-pr-eventrequest-tool -> % ls go.mod
main.goを作成し、以下の内容を保存。
package main import ( "fmt" ) func main() { fmt.Println("Hello world") }
git initを実行し、gitのリポジトリを作成。
GitHubの方でもリポジトリを作成し、push。（該当コミット）
2. ワークフロー設定前にブランチを作成し、作業分をコミット
-> % git checkout -b verify_actions_based_branch
func main() {
- fmt.Println("Hello World")
+ fmt.Println("Hello World without Github Actions!")
}
変更分をコミットし、PR作成に備える。
- PR = Pull requests
3. ワークフローの設定と確認
ワークフロー設定用のブランチを作成し、.github/workflows内に、2つのyamlを設定。
（該当コミット - ディレクトリ名間違えてるので、次のコミットで修正）
name: pushイベントで発火するワークフロー
on:
push
jobs:
check_push_event_workflow:
runs-on: ubuntu-latest
steps:
- run: echo "Hello World with push event"
と
name: pull_requestイベントで発火するワークフロー
on:
pull_request
jobs:
check_pull_request_event_workflow:
runs-on: ubuntu-latest
steps:
- run: echo "Hello World with pull request event"
変更分をコミット、GitHubにpush + PRを作成しActionsタブを確認。
4. ワークフローを含まない作業ブランチでPR作成
「2. 」で作成した作業コミットをpushし、PRの作成。
この時に、pull_requestイベントのみ発火されていれば仮説は検証される。
PR上とActionsタブで確認。
このシンプルな構成で仮説通りに実行されたので、他の要因ではなくイベント毎に使用するワークフローが違うことが理解できた。
作業ブランチの方にワークフローが無かったからベースブランチの方を利用したとかではなく、イベント毎に見るブランチが変わることが公式ドキュメントに書かれているだろうと思うので、そちらを調べてみる。
公式ドキュメント編
実際に両イベントの確認
この時点で今回の内容に関係がありそうなのは、GITHUB_REFという項目。
なので次はこの項目を深掘り。
GITHUB_REFについて
ワークフローの実行をトリガーしたブランチまたはタグの完全な形式の参照。
というか！！！！これの続きにそれっぽいことが書いてある！！！！
push によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 pull_request によってトリガーされるワークフローの場合、これは pull request のマージ ブランチです。
ふむふむ。なるほど。
今回の例だと、pushイベントがGITHUB_REF = プッシュされたブランチの参照、pull_requestイベントがGITHUB_REF = pull request のマージ ブランチの参照になるって訳だ。
想定通りだな。ここで出てきた「ワークフロー」と「トリガー」で調べた所、以下のページを発見。
各ワークフロー実行では、そのイベントに関連付けられたコミット SHA または Git ref に存在するワークフローのバージョンが使用されます。
ここですね。つまり上の両イベントに紐付くGITHUB_REF（ブランチ）にあるワークフローを利用すると。
ここまでこれば、ほぼ終わりですがちゃんと確認をして終わりたいと思います。
両イベント時のGITHUB_REFを確認
先ほど作成したブランチにGITHUB_REFを確認するコマンドを追加し、再度Acitonsを実行。
steps:
- run: echo "Hello World with push event"
+ - name: Check GITHUB_REF
+ run: |
+ echo "GITHUB_REF: $GITHUB_REF"
+ echo "GITHUB_REF_NAME: $GITHUB_REF_NAME"
+ echo "GITHUB_SHA: $GITHUB_SHA"
ここでの想定では、上に書いた通り。
pull_requestイベントのGITHUB_REFが想定外。
どういう意味か全くわからないので、次はこれを調べる。
refs/pull/1/mergeについて
GitHub Actionsの公式のサイトからは定義や役割をあまり見つけられませんでしたが、Gitの公式サイトで見つけたのでそちらを参照します。
There’s also a refs/pull/#/merge ref on the GitHub side, which represents the commit that would result if you push the “merge” button on the site. This can allow you to test the merge before even hitting the button.
GitHub 上には、これだけではなく refs/pull/#/merge という参照もあります。 これは、サイト上で「マージ」ボタンを押したときに作られるコミットを指す参照です。 これを使えば、マージしたらどうなるかを、ボタンを押す前に確かめることができるのです。
つまりrefs/pull/1/mergeは、マージ元ブランチとマージ先ブランチを一時的に仮マージした参照と理解。
ここまでこれば、ほぼ終わり
大フラグですね（お前は何も分かっていない！！！）
ちゃんと検証して良かった！！！！！！！！！！！
（メモ）
pull_request によってトリガーされるワークフローの場合、これは pull request のマージ ブランチです。
今後このpull requestの「マージ ブランチ」は、「一時的に仮マージしたブランチ」と読む。
なので、両イベント（ワークフロー）が含まれるブランチを対象にpull_requestイベントが発火したので、pushイベントは実行されずにいた。ということが説明可能に。
完全に理解した
