初投稿&初アドカレなのでご容赦を
アドバイス、補足等も大歓迎です!
最近暇になったのでMinecraftのMod開発を始めました。最初は完全に趣味だったので雑に管理していたのですが、作業を進めるうちに公開したくなりました。
Git自体はそこそこ使っていたのですが、GitHubで本格的に公開したり管理したりの経験が無かったため挑戦してみることに。初めてREADME.mdを書いたり、LICENSEについて調べたり...
そしてアプリの配布方法や自動化について調べていたところ、今回の問題に遭遇しました。
前提知識
GitHub Actionsとは
GitHub Actionsについて、公式のドキュメントでは以下のように説明されています。
GitHub Actionsで、ソフトウェア開発ワークフローをリポジトリの中で自動化し、カスタマイズし、実行しましょう。 CI/CDを含む好きなジョブを実行してくれるアクションを、見つけたり、作成したり、共有したり、完全にカスタマイズされたワークフロー中でアクションを組み合わせたりできます。
要はGitHub上でいろいろな作業を自動化できる機能です。変更をGitHub上にPushしたタイミングで自動的にビルドやユニットテストを行ったり、依存関係を自動的に更新したりできます。
GitHubからいろいろダウンロードするときによく見るReleaseも大体のプロジェクトでは自動化されていると思います。

RTKLIB_EXのリポジトリでの例
今回はリリースを作成した後の成果物のビルドとアップロード作業を自動化しようと思ったところ、この問題に直面しました。
ワークフローの作成
Geminiに頼んでリリース作業の自動化フローを作成してもらいました。
ざっくり解説すると、onは処理を開始する条件、permissionsはこのワークフローが持つ権限、jobsは処理の内容です。今回のjobsにはMinecraftのModをビルドする処理が書かれています。
name: Release
on:
release:
types: [created]
permissions:
contents: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0 # タグ情報を取得するために必要
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
java-version: '21'
distribution: 'temurin'
- name: Grant execute permission for gradlew
run: chmod +x gradlew
- name: Build with Gradle
run: ./gradlew build
- name: Upload Release Assets
uses: softprops/action-gh-release@v2
if: startsWith(github.ref, 'refs/tags/')
with:
files: |
<プロジェクト1>/build/libs/<成果物>-*.jar
<プロジェクト2>/build/libs/<成果物>-*.jar
これをgitリポジトリと同じディレクトリにある.github/workflows内へ入れると晴れて設定完了。簡単だね!!
【悲報】ワークフローを設定したのに自動実行されない!!
マジでうんともすんとも言わない。
トラブルシューティング
よくあるミスとしてGitHubリポジトリにActionsの実行権限が無いということがあるらしいので確認しました。実行権限はSettings->Actions->General内のActions permissionsを適切なものに変更してSaveします。今回は初めから一番緩いAllow all actions and reusable workflowsにチェックが入っていたため直接の原因ではないと考えました。

下にあったWorkflow permissionsの設定も怪しいため、Read and write permissionsに変更するも変化なし。
トリガーの設定の間違いが原因かと思いドキュメントを確認してtypesをpublishedやreleasedに変更したりもしましたが、全く動かず。
調べると、GitHub Actionsが動かない?トリガーの設定ミスをチェックしようという記事があったため、それを参考に
env:
ACTIONS_STEP_DEBUG: true
を追加するも効果なし。
そもそも処理がトリガーされていないようなので、記事にある通り手動トリガー実行が可能かどうかを確認してみることにしました。
原因
結論から言うと、初歩的なミスでした。 タグを作成した時点に、このワークフローファイルがリポジトリ内に存在しなかったため実行されませんでした。
解決するには、ワークフロー作成後のコミットに対して再度新しいタグを作成し、それをリリースします。
GitHub Actionsは、イベントが発生した時点(この場合はタグが作成された時点)のコミットに含まれるワークフローファイルを参照して実行される仕様です。 今回リリースしようとしていたタグはワークフローを追加する前のコミットに対して作成していました。そのため、そのタグのコミットには release.yml が存在せず、当然Actionsもトリガーされないというわけです。
まとめ
ワークフローに限らず、CI/CDの設定はプロジェクトの初期段階で行うのが吉。 もし後から追加したワークフローを使用する場合は、「そのタグの時点にワークフローファイルが存在するか?」を意識する必要があります。
余談
どのようにして気づいたのか
以下のようにworkflow_dispatchをトリガーに追加するとActions管理画面にグレーの実行ボタンRun Workflowが追加されます。
on:
release:
types: [created]
workflow_dispatch:
このグレーの実行ボタンを押すと以下のようなダイアログが表示されます。
現在はmainブランチが指定されているが、ここを作成したTagに変更して実行すると、
Workflow does not exist or does not have a workflow_dispatch trigger in this tag.
ワークフローが存在しないか、このタグに workflow_dispatch トリガーがありません。
と表示されました。
ならリリースとかタグとかに関連するActions自体の動作確認って難しくね?
ワークフローを自分で書くような場合には動作確認毎にコミットする必要もありますし、リリースやタグ関連では都度タグの作成と削除を繰り返す必要があるのは厄介そう。今はもうAIで自動作成できるとは思いますが...
少し状況は違いますが、この記事が参考になるかもしれません。
GitHub Actions でデフォルトブランチにないワークフローの動作確認をする
トリガーされるかどうかの確認はできませんが、Job自体が正常に動作するかどうかは確認できそうです。
まぁ要はトリガーにworkflow_dispatchを必ず併記するようにしとけば大体なんとかなるんじゃないんですかね()




