これまでこのブログは元のソースコードはBitbucketのプライベートレポジトリで管理し、 werckerを使ってpushした際にビルドしてGitHubに送ってGitHub pagesを通して公開、 ということをしていました。
それをソースコードの管理もGitHubに移行して ビルドをGitHub Actionsを使ってやるようにしてみました。
GitHubのプライベートレポジトリへ移行
だいぶ前に無料でもプライベートレポジトリが使える様になったり、 先日無料の利用が強化されて 1 何人とでもプライベートレポジトリを共有できる様になったりと、 今となってはプライベートレポジトリに関して最も制限が少ないとも 言えるGitホスティングサービスになってきたGitHubなので これまでBitbucketで管理していたブログのソースコード部分をGitHubに移行しました。
Bitbucketはプライベートレポジトリが無料で使える、というだけの理由で ブログのソースコードに関してだけ使っていたので。
GitHub Actionsのプライベートレポジトリ対応
wercker はBitbucketやGitHubのプライベートレポジトリも無料で扱える、という理由で使っていました。
それ以外のCIなどは基本的にTravis CI を使っていました。
機能などについては、werckerの方はcron的に定期的に自動で走らせる様なことが出来ないなど いくつか不満なところがありました。
ただ、Travis CIはプライベートレポジトリを見るためには有料になります。
そんなかGitHub Actionsがリリースされ、最終的にyamlファイルで管理するような 他のCIサービスと同じ様な使用感になり、 またやはりGitHubのものということで盛り上がってactionsと呼ばれるモジュールも沢山 作られてきて良い感じになっています。
環境もMicrosoftの買収が良きに働いてる感じで、 Azure環境で動いて他のサービスよりサクサク動いている感じ。
使える環境もLinux(Ubuntu)とmacOSに加えてWindowsもあります。 また、Dockerを使った実行も出来るのである意味なんでもありです。
GitHub Actionsに関してはGitHubのレポジトリ限定になりますが、 プライベートレポジトリに関しても無料でも扱えます。
ただし、少し制限があってプライベートレポジトリに関しては無料だと月2000分まで、 となっています。 それ以上は従量課金になります。 (デフォルトの設定だと従量課金部分は0円まで、という制限にしてあって自動でお金がかかることはありません。)
ただし有料版でもTeamで3000分まで、とかなのでこれを使い切る、という以外では このために有料にする、という意味はあまり無いかも。
Linuxだと過剰部分は$0.008/minの課金なので $8/1000minになって3000分以上使うなら Team($4/month)にしたほうが安くなってきますし、macOSだと $0.08/minなのでよく使う(毎日2時間とか)なら超えるかもしれませんが。
この辺の料金に関してはまだちょっと記述が古くてPro
の料金とTeam
の料金が出ています。
ただ、GitHubのプランを直接見ると、そもそもPro
はすでになく、Team
が3000分使えるよ、
とかなっています。
今のブログのビルドは大体10分程度なので、毎日1回定期的に更新するジョブと、 新しくブログを書いた時に多くて1日数回、とかなので 2000min/monthでも十分な量です。
werckerのジョブを移行してみる
werckerで実行しているジョブを移行しています。
基本的にはyamlファイルに実行コマンドを羅列しているようなもので、 後はサービスごとに違うのはトリガーの設定や環境の設定などです。
元のwerckerの設定はこんな感じ
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 |
|
WerckerではDocker環境を使いますが、RubyのDockerを使っています。
後はbuild
というジョブの中でsteps
で実行することを定義してあります。
script
のcode
というのがコマンドラインから実行するコマンドそのままのやつです。
add-ssh-key
などは事前に定義されているモジュールのようなもので
必要なキーワードを与えて実行させています。
これをGitHub Actionsにしてみるとこんな感じ。
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 36 37 38 |
|
環境はruns-onでUbuntuに設定。
steps
の中でrun
となってる部分がコマンドを直接実行する部分で
werckerのcode
をそのまま移せば良し。
事前に定義されているモジュール(actions)はuses
を使って利用します。
上ではレポジトリを取ってきたり、Rubyの環境を作ったり、 sshの鍵を登録したり、というところ。
後は最初の部分でon
がありますが、これが実行するためのトリガーで、
master
ブランチにpush
したときか
毎日0時0分(UTC)に定期実行する様にしています。
細かい書き方(on
とかjobs
だとか)は公式のドキュメントがよくまとまっていますし、
上の様に全体的な流れは他のCIサービスと似た様なものなので
他のCIサービスを使ったことがあればそんなに苦労すること無く移行することが出来ると思います。
各言語環境に関する例など: starter-workflows/ci at master · actions/starter-workflows
アクションを作って使う
今、上の様な作業を日本語版ブログと英語版ブログの両方についてやっています。 (英語版はほとんど更新してないですが。。。)
ワークフローとしては全く一緒なので、これらを一つのアクションとして定義して それを使うようにしてみます。
作ったアクションはこれ。
これを使うと
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
の様な感じで各レポジトリのワークフローの定義をシンプルにすることが出来ますし、 他のレポジトリでの再利用が可能になります。
GitHub Marketplace に公開すれば他の人からも簡単に検索されるようになります。
ここに公開しなくてもパブリックレポジトリならレポジトリさえ知っていれば 他の人でも使うことは出来ます。
-
Proがなくなり有料は最小がTeam、それでも$4/monthで以前の Pro($7/month)より低い。 ↩