開発効率を少しだけ上げるGithubActionsの便利な使い方
2023.10.04
普段使ってるGithub ActionsのWorkflowを紹介
（株）ライトコードでモバイルアプリケーションメインで色々開発している笹川（ささがわ）です！
今日は普段私が業務や個人開発で利用しているGithub ActionsのWorkflowをいくつか紹介したいと思います。
リリースノートを自動で生成してくれる
release-drafterというWorkflowを使えば簡単にできます。
これは結構有名で使っている方も多いと思います！
使い方としては.github/と.github/workflows/にそれぞれ release-drafter.ymlを作成し、ぞれぞれ下記の様に記載します。
.github/release-drafter.yml
こちらではPRに付けたLabelを元にどのような変更のカテゴリになるかの設定やリリースバージョンをどの単位で自動生成していくかを設定しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | name-template: 'v$RESOLVED_VERSION' tag-template: 'v$RESOLVED_VERSION' categories: - title: '🚀 Features' labels: - 'feature' - 'enhancement' - title: '🐛 Bug Fixes' labels: - 'fix' - 'bugfix' - 'bug' - title: '🔓Security' label: 'security' - title: '😐 Maintenance' labels: - 'chore' - 'test' - 'refactoring' - 'dependencies' change-template: '- $TITLE @$AUTHOR (#$NUMBER)' version-resolver: major: labels: - 'major' minor: labels: - 'minor' patch: labels: - 'patch' default: patch template: | ## Changes $CHANGES |
.github/workflows/release-drafter.yml
こちらではどのタイミングでリリースノートの生成を行うかの定義をしています。
こちらの設定だと developブランチにマージされたタイミングで実行されるようになっています。
運用によっては mainブランチにするなどができます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | name: Release Drafter on: push: branches: - develop jobs: build: runs-on: ubuntu-latest steps: - uses: release-drafter/release-drafter@v5 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
正直、Workflowの中では少し手間な部分がありますが、それでも自分で「あれ、このリリースに含まれるのはどれだっけ？このPRはどんな修正だっけ？」と全てのPRを再確認するよりは圧倒的に作業効率は良くなりますね！
PR作成時にDangerを動かしてLint実行
DangerというRuby製のLintを実行してくれるツールがあります。
こちらはGithub Actionsが登場する前から広く使われており、様々な言語やFWで使うことができます。
少し名前が物騒ではあるのですが、とても便利なのでぜひ知っていただきたいです。
今回はAndroidアプリケーション開発で良く使われているKtlintを利用する想定で紹介します。
他の言語についてはDangerのドキュメントに利用方法が書いてありますので、そちらをご覧ください。
.github/workflows/pull_request.yml
こちらはrelease-drafterみたいに専用のworkflowがないので、自分でymlに書いていく必要があります。
developブランチとfeatureブランチに対してPRが作成されたら実行され、Dangerのインストールと実行までを定義しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | name: Android CI on: pull_request: branches: [ develop, "feature*" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: set up JDK 11 uses: actions/setup-java@v1 with: java-version: 11 - name: Set up Ruby 2.6.0 uses: ruby/setup-ruby@v1 with: ruby-version: 2.6.0 - name: Install run: | gem install bundler bundle install --jobs 4 --retry 3 curl -sSLO https://github.com/pinterest/ktlint/releases/download/0.36.0/ktlint chmod a+x ktlint sudo mv ktlint /usr/local/bin/ - name: Run Unit Test run: | bundle exec fastlane unit_test env: GITHUB_TOKEN: ${{ secrets.DANGER_GITHUB_API_TOKENCI }} |
これだけだとDanger自体の実行ができないので他に必要なファイルも用意します。
私の環境ではCLIツールのFastlaneを利用しているので、そちらも導入しております。
モバイルアプリケーションじゃない場合はFastlaneは使わず、Dangerのドキュメントにある様にymlファイルを定義してもらえれば動くはずです。
他の必要なファイルは複数あるのでこれらのファイルをそれぞれ参照してください。
Androidのネイティブアプリではコピペでほぼ利用できるかと思います。
私の環境ではUnitTestも同時に実行しているので、そちらが邪魔であればFastfileの gradle(task: "library:test")を削除してください。
mainブランチとdevelopブランチの差分を自動でPR作成してくれる
hotfixなどでmainブランチにマージした場合、developブランチにマージする必要がありますが、意外と忘れがちです。
これを自動生成してもらうことで差分が開いてからの取り込みを防ぐことで、コンフリクトや先祖返りなどのリスクも減らすことができます。
.github/workflows/master-diff.yml
こちらもrelease-drafterみたいに専用のworkflowがないので、自分でymlに書いていく必要があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | on: push: branches: - master jobs: master-to-develop-pr-auto-creator: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Check change run: | git fetch echo "::set-output name=CHANGED::$(git diff --name-only "origin/develop" "origin/master" -- | wc -l | awk '{print $1}')" echo "::set-output name=COMMIT_HASH::$(git rev-parse HEAD)" id: check-change - name: Create branch if: ${{ steps.check-change.outputs.CHANGED > 0 }} run: | git checkout -b "fix/${{ steps.check-change.outputs.COMMIT_HASH }}" git push origin "fix/${{ steps.check-change.outputs.COMMIT_HASH }}" - name: Create pull-request if: ${{ steps.check-change.outputs.CHANGED > 0 }} uses: repo-sync/pull-request@v2 with: source_branch: "fix/${{ steps.check-change.outputs.COMMIT_HASH }}" destination_branch: "develop" github_token: ${{ secrets.GITHUB_TOKEN }} pr_title: "Merge diff of Master for Develop" pr_body: "Auto Create PR" pr_label: "master-diff" |
pr_titleとpr_bodyは好きに記載してください。日本語も書けますよ。
pr_labelはLabelを作成し、それに紐づく様に設定しています。
おまけ READMEの肥大化はGithub Pagesを使おう
アプリケーションが育ってくるとREADMEに記載される内容が肥大化していきます。
Wikiを使う方法もありますが、Git管理したいケースもあると思います。
その場合はGithub Pagesを使えば解決できます！
登場した時点ではpublicリポジトリのみの対応でしたが、今ではprivateリポジトリでも利用可能になっております。
詳しい設定方法などはGithub Pagesの公式ドキュメントを参照してください。
笹川はソースコードのドキュメント（Jdoc）の様なものをKotlinで使える様にして利用しております。
https://sasa-nori.github.io/common-ktx/
人の手でやらなくていいのはやらなくていいいんです！
いかがだったでしょうか？
今日にでもコピペで使えるものもあったかもしれませんね。
笹川の個人開発しているOSSでも今回のWorkflowは全て導入されておりますので、そちらを参考にしてください。
https://github.com/sasa-nori/common-ktx
OSS開発した際の記事はこちら
Androidのライブラリを作って公開してみた
書いた人はこんな人
- 新潟生まれ新潟育ち本業はモバイルアプリエンジニア。
日々、猫(犬)エンジニアとして活躍中！
IT技術9月 20, 2023開発効率を少しだけ上げるGithubActionsの便利な使い方- IT技術4月 7, 2023【ISUCON部】ライトコードISUCON部 始動！
- IT技術4月 18, 2022【Android】Webでよくみる入力Boxを手作り
- IT技術1月 19, 2022【Android】SeekbarでスイッチなUIを作る
関連記事
採用情報
\ あの有名サービスに参画!? /
バックエンドエンジニア
\ クリエイティブの最前線 /
フロントエンドエンジニア
\ 世界を変える…！ /
Androidエンジニア
\ みんなが使うアプリを創る /
iOSエンジニア
