🧰

(2日目)社内の皆が使える GitHub Actions テンプレート集を作成した

2022/12/02に公開

こんにちは、ikkitangです。

この記事は スターフェスティバル Advent Calendar 2022 の2日目の記事です。

昨日は kajiken さんのGo All Outなチームの作り方でした。

自分は今はkajikenさんとは別のチームで、チーム外の人間という事になるのですが kajikenさんのチームのSlackチャンネルに所属してると上記のチームに対する取り組みとかが伺え知れたりします。(真似していきたい)

さて、本題

という事で本日は、GitHub Actionsについて書いていきたいと思います。

以前、別記事でGitHub Actionsについての記事を書いたんですが、それなりに好評を頂けたと思っています。普段の開発でも、GitHubとの親和性の高さからまず候補にあがるCI/CD環境かと思います。
https://zenn.dev/stafes_blog/articles/ikkitang-a694b8afeb66f5

弊社でも8割以上の環境でGitHub Actionsが採用されています。
ただ、GitHub Actions、運用していく内に「あぁ、こういうの他で書いたなー」ってのなる経験も多いと思います。そこで今回は、そういった共通で使えるGitHub Actionsを社内用途として管理した話、また広く使ってもらえる為のドキュメント整備した事とかを書いてみたいと思います。(スタフェスの人、知らなかったら使ってください && チームで共通化出来そうな GitHub Actionsのワークフローがあれば共有ください!!!!)

共通化する為の設計ポイント

先程、URLを貼った "GitHub Actionsの共通したアクションを切り出してシンプルに保つ" で紹介した通り、 GitHub Actions では Composite action という仕組みを使って共通化したアクション群を一つのWorkflowとして切り出す事が可能なので、こちらを用いて共通化を行う事としました。

ただ注意事項として、Composite action で共通Workflowを提供する場合 Public Repository であるか、Private Repository であるかによって、利用者側からどのように呼び出すかが変わって来ます。なるべく Public として提供するのが望ましいかとは思いつつも、今回は AWSのECRにDocker ImageをPushする機能 とかを管理したかったという所から Access Token などの機密事項を扱う想定でしたので一旦 Private で始める事としました。

前述した Private Repository の特殊な呼び出し方は、例えば、Private Repository にある Composite actionのymlファイルを一度ローカルに git clone してくるといった形で、各利用者側の GitHub Actions において実行時に ymlファイルにアクセス出来る状態を作る必要があるという事でした。(こちらの仕組みは後述します)

また、Composite action では 呼び出し側のsecretsにアクセスする事が出来ない為、機密情報は利用者側からもらうという構築が必要でした。こちらも Composite action では引数が外部から受け取る事が出来るので、それを利用すれば良いですね。

これでだいたいの目処、抑えるべきポイントが見えてきたので、手を動かしていきました。

作成にあたって気をつける事

共通化として切り出すにあたって以下の事を気を付けました。

  • ドキュメントをちゃんと書く(どういう風に使えばどういう事が起こるかが分かる事を意識する)
  • 可能な限りシンプルにする

今回は、呼び出し側に「Private Repositoryを呼び出す為のCheckout作業」という一手間を行ってもらう必要があったり、引数から機密情報をもらう想定で作っています。共通化したいのに、利用者が利用するのに面倒くさいという状況は可能な限り避けたく、ドキュメントをちゃんと書いた気持ちです。

また、共通化として切り出すWorkflowは可能な限りシンプルにする事を心がけていました。例えば、 内部では基本的にはifを使わないといった状態にする / また、1センテンスでこの Composite action は何が出来るものかってのを表せる粒度にするぐらいの事を気をつけたつもりです。まあ、これは GitHub Actionsに限らずメソッドを実装する時の考え方ですよね。

共通化Workflowの成果物

まず作った物としては、 developブランチ(指定のブランチ)からmainブランチに向けてPRを自動で作成する共通Workflowでした。
弊チームでも複数のBacklogが平行して動いていたりする関係上、Git-Flowを導入せざるを得ないリポジトリが存在しており、developブランチを作成して受け入れが完了したタイミングでmainブランチへマージするといった運用を取っていました。

課題感として、develop から main へのプルリクエストを作成するのに、わざわざ開発者がプルリクエストを作成するといった事が必要な事であり、これの何が問題かというと 既に全てレビューが通った物を再度見てもらう必要がある という点でした。レビュー依頼をしたとしても、これまでのdevelopへのマージが全て凝縮された巨大なプルリクエストになる事から、レビューフローがあってないような物になっていました。

機械的にプルリクエストを作成する事で、チームの誰であってもそのプルリクエストをレビューしてマージする権限を持つ事が出来る為、運用上の複雑度が下がるメリットがあり、導入しておりました。(ちなみにリリースOKの判断は別途 PdM/TechPdMが下しております)

ymlとしてはまあありがちな物なので公開しますが、こんなWorkflowを作成しました。

name: "Create Pull Request to Main"
description: "Create Pull Request To Main"

inputs:
  base-branch:
    description: main に向けて Pull Request を作るベースブランチ
    required: true

  github-token:
    description: GitHub access token to create pull request
    required: true

  main-branch:
    default: "main"
    description: main ブランチの名称 (mainにしていきましょうね)
    required: false

runs:
  using: "composite"
  steps:
    - name: Create Pull Request
      uses: vsoch/pull-request-action@1.0.23
      env:
        GITHUB_TOKEN: ${{ inputs.github-token }}
        PULL_REQUEST_BRANCH: ${{ inputs.main-branch }}
        PULL_REQUEST_FROM_BRANCH: ${{ inputs.base-branch }}
        PULL_REQUEST_TITLE: "[CI] ${{ inputs.base-branch }}を${{ inputs.main-branch }}へマージ"
        PULL_REQUEST_BODY: ""

また、ドキュメントとしては以下のような物を作成しました。 パッと見で何が出来るかとか、どういう風に使えば期待する動きが得られるかみたいなのが分かるのかな、と思ったりしております。


Create Pull Request to Main

  • Main ブランチに向けて PullRequest を自動で作成する共通Workflow

Example

name: Create Pull Request to main

on:
  push:
    branches:
      - develop

jobs:
  patch:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3.0.2

      - uses: actions/checkout@v3.0.2
        with:
          repository: stafes/some-private-repository
          ref: main
          token: ${{ secrets.NAME_OF_GH_TOKEN }}
          path: .some-private-repository

      - name: Create Pull Request to main
        uses: ./.some-private-repository/create-pull-request-to-main
        with:
          base-branch: "develop"
          github-token: ${{ secrets.NAME_OF_GH_TOKEN }}

input

Name Description
base-branch main に向けて Pull Request を作るベースブランチ
github-token Pull Request を作る時に使用する Token
main-branch main ブランチ名 (master の時用)

総括

  • 共通Workflowはシンプルであるのが望ましいと思います
  • 実際に他チームに共有するときも、ここにあります って話だけで通じた気がしていて作っておいてよかったな、という感じがしました
  • さて、他にも色々と共有出来るWorkflowを思いつき始めたのでプルリクエストを作りたい欲が出てきました

採用頑張っております

という事で、今採用活動頑張っております。

https://stafes.notion.site/stafes/d0996a00d77d418280982797c7e16001

雰囲気もこの辺で感じてもらえそうです!

https://zenn.dev/stafes/articles/yamazaki-1m-entry

https://zenn.dev/stafes/articles/dpontaro-join-1month

カジュアル面談からやっておりますので、必要な方は @ikkitangのTwitter までDMくださいませ〜〜〜!!

スタフェステックブログ

Discussion