stp というLambda、DynamoDB、S3を使って小規模なCDNを構成できるものを作っているのだが、それのヘルパーとして stph も用意している。 stphは単純にブログに画像を載せるときにMarkdownコードと画像を表示してくれたり画像の削除をしてくれるローカルで動作するサーバなので、バイナリ単体で動作するようになっている（設定ファイルは必要）
ということでstphを更新した時に自動でそのバイナリをassetsとしてGithubに登録したいなと思いせっかくなのでGithub Actionsを使ってみた。
結構日本語化されているようなので読みやすくて嬉しい
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.10nameはワークフローの名前.省略した場合はリポジトリのルートに対するワークフローファイルの相対パスを自動で設定する。
onで特定の動作の時のみワークフローが動作するように設定できる。 上記の場合は masterブランチに大してpush、かつtagがvから始まる名前の時に動作させられる。 pushの他、pull_requestやschedule（cron構文で設定）等も設定できるようだ。
branches-ignoreなどで無視する設定もできるようなので、結構柔軟に設定できそう。
ワークフローのメインとなる部分。 ビルドやテスト、リリースの設定を定義していく。
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: gousesが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.htmlrunで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/zipcreate-release, upload-release-assetというactionを使ってリリースの作成と、作ったリリースに対してassetを紐付けるアップロードする。
これらのactionは公式提供されており、withでリリースやassetについて指定していく。
Circle CI等もこういったyaml（ベースの拡張されたもの）でフローを指定すると思うのだが、yamlベースでこういったフローを記入していく形式はソフトが複雑になればなるほどこのファイルも複雑になっていきそうだなと思った。（歴史の長いモノリスなソフトのmakeファイルが大きく複雑になっていく現象と同じ道を辿りそう）
個人的にはyamlはソフトが動作するための設定ファイルとしてなら書きやすくて好きだけど。
フローが複雑になればなるほど変数や分岐が多くなるので、結局何らかのプログラミング言語を利用するほうが後々は楽になるのではないかな。
ひとまずGitHubを使う分には便利なactionが揃っていると思うしGitHub公式も力を入れてそうな感じなので、GitHubにリポジトリおいている小さめのソースコードなら利用するのにはいいかな～と今の時点では思っている。