はじめに
先日、業務でGitea Actionsを使ってCI/CDを構築してみました。
今回は構築の際に実際にGitea Actionsの仕組みについて学んだことを整理していこうと思います。
※GitHub Actionsと互換性があり、ほぼ同じ仕組みなので、GitHubに慣れている方は、そのままCI/CDを構築できるかと思います。
そのため、GitHub Actionsで構築したい場合も、この記事に記載ある「Gitea」→ 「GitHub」と読み変えて読んでいただければいいと思います。
1. Gitea Actionsとは
Gitea Actionsは、Gitへの操作などをきっかけに、あらかじめ定義した処理を自動実行する仕組みです。
例えば、
- ビルド
- テスト
- デプロイ
といった処理を自動化できます。
WorkflowというYAMLファイルに、
- 何をきっかけに実行するか
- 何を実行するか
を定義していきます。
2. Workflow・Job・Step
Gitea Actionsでは、主に以下の3つを考えると分かりやすいです。
| 用語 | 役割 |
|---|---|
| Workflow | 一連の自動処理全体 |
| Job | 実行する処理のまとまり |
| Step | Jobの中で実行する個々の処理 |
例えば、
jobs:
build:
steps:
- run: mvn clean package
- run: mvn test
とした場合、
Workflow
Job: build
Step: mvn clean package
Step: mvn test
という構造になります。
3. 実際に処理するのはRunner
Gitea Actionsでは、Gitea自身がMavenなどのコマンドを実行しているわけではありません。
Runnerという実行環境がJobを受け取り、実際の処理を行います。
大まかな流れは次のようになります。
| 要素 | 役割 |
|---|---|
| Gitea | WorkflowやJobを管理する |
| Workflow | 実行する処理を定義する |
| Job | 実行する処理をまとめる |
| Runner | Jobを実際に実行する |
| Step | MavenやAntなどの処理を実行する |
つまり、
Gitea = Jobを管理する側
Runner = Jobを実行する側
と考えると分かりやすいです。
4. runs-onとは
Workflowでは、次のような記述をすることがあります。
jobs:
build:
runs-on: windows
これは、
windowsというラベルを持つRunnerで、このJobを実行する
という指定です。
Runnerにはラベルを設定できるため、複数のRunnerがある場合でも、実行する環境を分けることができます。
例えば、
Linux用Runner
Windows用Runner
のように用意しておき、Workflow側で実行先を指定できます。
今回のようにWindows上でMavenを実行したい場合も、WindowsのRunnerを用意してJobを実行させる、という考え方になります。
5. Gitea Actionsの全体の流れ・まとめ
最後に、実際にpushしてから処理が終わるまで流れを整理します。
| 番号 | 処理 | 内容 |
|---|---|---|
| ① | Gitにpush | 開発者がソースコードをGiteaへpushする |
| ② | Workflowを確認 | Giteaがpushを検知し、実行条件に一致するWorkflowを確認する |
| ③ | Jobを実行 | Workflowに定義されたJobが実行対象になる |
| ④ | Runnerが実行 | 対象のRunnerがJobを受け取る |
| ⑤ | Stepを実行 | Workflowに記述されたMavenやAntなどの処理を実行する |
| ⑥ | 結果を確認 | Jobの成功・失敗や実行ログをGitea上で確認する |
CI/CDをどうやって構築するのか私も最初わかりませんでしたが、
やってることは、サーバー上のコマンドで、ビルドしたり、テストしたり、デプロイするといった単純なことの組み合わせです。
そして、それぞれの役割をまとめると、
GiteaがWorkflowやJobを管理し、Runnerが実際の処理を実行する
となります。
これを知っているだけでも、知らなくて怖い状態から、だいぶ何をすればいいかがわかるかと思いますので、
ご参考までに今回は、学んだことを整理してみました。