GitHub Actions

GitHub Actionsを使ってみた感想

GitHub Actionsを使ってみた

きっかけ

stp というLambda、DynamoDB、S3を使って小規模なCDNを構成できるものを作っているのだが、それのヘルパーとして stph も用意している。 stphは単純にブログに画像を載せるときにMarkdownコードと画像を表示してくれたり画像の削除をしてくれるローカルで動作するサーバなので、バイナリ単体で動作するようになっている（設定ファイルは必要）

ということでstphを更新した時に自動でそのバイナリをassetsとしてGithubに登録したいなと思いせっかくなのでGithub Actionsを使ってみた。

GitHub Actionsのドキュメント

結構日本語化されているようなので読みやすくて嬉しい

GitHub Actionsのコード

コード自体はこちら: auto_release.yaml

name: Go

on:
  push:
    branches: [ master ]
    tags:
      - 'v*' # Push events to mathcing v*, i.e. v1.0, v20.15.10

jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:

    - name: Set up Go 1.x
      uses: actions/setup-go@v2
      with:
        go-version: ^1.13
      id: go

    - name: Check out code into the Go module directory
      uses: actions/checkout@v2

    - name: Get dependencies
      run: |
        go get -v -t -d ./...
        if [ -f Gopkg.toml ]; then
            curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
            dep ensure
        fi
                
    - name: PreBuild_Linux
      run: mkdir linux_bin

    - name: Build for Linux
      run: GOOS=linux GOARCH=amd64 go build -v -o stph .

    - name: PreBuild_Win
      run: mkdir windows_bin

    - name: Build for Windows
      run: GOOS=windows GOARCH=amd64 go build -v -o stph.exe .
    
    - name: Create Artifact
      run: zip stph.zip -r stph stph.exe configs/sample_settings.yaml templates/stph.html

    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
      with:
        # The name of the tag. This should come from the webhook payload, `github.GITHUB_REF` when a user pushes a new tag
        tag_name: ${{ github.ref }}
        # The name of the release. For example, `Release v1.0.1`
        release_name: Release ${{ github.ref }}
        # `true` to create a draft (unpublished) release, `false` to create a published one. Default: `false`
        draft: false
        # `true` to identify the release as a prerelease. `false` to identify the release as a full release. Default: `false`
        prerelease: false
    
    - name: Upload a Release Asset
      uses: actions/upload-release-asset@v1.0.2
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
      with:
        # The URL for uploading assets to the release
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        # The path to the asset you want to upload
        asset_path: ./stph.zip
        # The name of the asset you want to upload
        asset_name: stph.zip
        # The content-type of the asset you want to upload. See the supported Media Types here: https://www.iana.org/assignments/media-types/media-types.xhtml for more information
        asset_content_type: application/zip

こんな感じで yamlをベースのGithub Actions用の拡張が入ったものを作っていく。おそらくCircle CI等のCIサービスやツールを使ったことのある人には馴染み深いものかなと思う（が、自分は使ったことがなかったので結構苦戦した）

以下いくつかメモ

特定の動作の時にワークフローを動かす

name: Go

on:
  push:
    branches: [ master ]
    tags:
      - 'v*' # Push events to mathcing v*, i.e. v1.0, v20.15.10

nameはワークフローの名前.省略した場合はリポジトリのルートに対するワークフローファイルの相対パスを自動で設定する。

onで特定の動作の時のみワークフローが動作するように設定できる。上記の場合は masterブランチに大してpush、かつtagがvから始まる名前の時に動作させられる。 pushの他、pull_requestやschedule（cron構文で設定）等も設定できるようだ。

ワークフロー構文

branches-ignoreなどで無視する設定もできるようなので、結構柔軟に設定できそう。

jobs設定

ワークフローのメインとなる部分。ビルドやテスト、リリースの設定を定義していく。

    runs-on: ubuntu-latest

ビルドが動作するコンテナ環境を指定できる。ubuntuだと18や20が指定できる（20は現時点ではプレビュー版)

    - name: Set up Go 1.x
      uses: actions/setup-go@v2
      with:
        go-version: ^1.13
      id: go

usesがGithub Actionsの特徴的な？もので、公式だったり他の人が作ってくれているActionsを流用して使うことができる。ここでは公式で用意されているGoの環境をセットアップするactionを指定している。

withでそのactionに対して入力を指定する。

    - name: Check out code into the Go module directory
      uses: actions/checkout@v2

ソースコードのチェックアウト

    - name: Create Artifact
      run: zip stph.zip -r stph stph.exe configs/sample_settings.yaml templates/stph.html

runでLinuxコマンドを指定して自分でアーティファクトを作る

    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
      with:
        # The name of the tag. This should come from the webhook payload, `github.GITHUB_REF` when a user pushes a new tag
        tag_name: ${{ github.ref }}
        # The name of the release. For example, `Release v1.0.1`
        release_name: Release ${{ github.ref }}
        # `true` to create a draft (unpublished) release, `false` to create a published one. Default: `false`
        draft: false
        # `true` to identify the release as a prerelease. `false` to identify the release as a full release. Default: `false`
        prerelease: false

    - name: Upload a Release Asset
      uses: actions/upload-release-asset@v1.0.2
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
      with:
        # The URL for uploading assets to the release
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        # The path to the asset you want to upload
        asset_path: ./stph.zip
        # The name of the asset you want to upload
        asset_name: stph.zip
        # The content-type of the asset you want to upload. See the supported Media Types here: https://www.iana.org/assignments/media-types/media-types.xhtml for more information
        asset_content_type: application/zip

create-release, upload-release-assetというactionを使ってリリースの作成と、作ったリリースに対してassetを紐付けるアップロードする。

これらのactionは公式提供されており、withでリリースやassetについて指定していく。

感想

Circle CI等もこういったyaml（ベースの拡張されたもの）でフローを指定すると思うのだが、yamlベースでこういったフローを記入していく形式はソフトが複雑になればなるほどこのファイルも複雑になっていきそうだなと思った。（歴史の長いモノリスなソフトのmakeファイルが大きく複雑になっていく現象と同じ道を辿りそう）

個人的にはyamlはソフトが動作するための設定ファイルとしてなら書きやすくて好きだけど。

フローが複雑になればなるほど変数や分岐が多くなるので、結局何らかのプログラミング言語を利用するほうが後々は楽になるのではないかな。

ひとまずGitHubを使う分には便利なactionが揃っていると思うしGitHub公式も力を入れてそうな感じなので、GitHubにリポジトリおいている小さめのソースコードなら利用するのにはいいかな～と今の時点では思っている。