Actionsが正式にリリースされました。ActionsはGitHubに組み込まれたCI/CD機能でpush等のGitHub上のイベントをトリガーに任意のアクションを実行できるものです。ActionsではDockerが使用できるので、様々な環境上でテストの実行やビルドなどができます。CIがありますが、AppVeyorは無料のプランだと、ワーカーがプロジェクトにつき1つなので、Groongaのように複数のパッケージを作成するためにジョブが多くなるプロジェクトだと、ビルドとテストの完了に時間がかかってしまい効率的ではありませんでした。Actionsでは、リポジトリーにつき20まで並列で実行できます。CIでは、ビルドした成果物を保存する場所がデフォルトで用意されていないため、正常にビルドできるかの確認やテスト実行はできますが、リリース用のパッケージを作成して置いておくということがやりにくいです。Actions上でパッケージを作成し、作成したパッケージを取得してリリース用のパッケージとしてアップロードするということがやりやすいです。Actionsへ移行しています。いままで、GroongaやMroonga、PGroongaのパッケージは開発者の手元でビルド、署名、アップロードを実施していました。GroongaとMroongaは毎月末にリリースがあるため、毎月末に開発者はパッケージを作る作業を実施しなければなりません。この際にパッケージの作成に失敗するような問題が発覚すると、問題の修正作業にも追われることになります。Actionsはpushトリガーでアクションを実行できるので、変更がリポジトリにpushされた段階でパッケージ作成することで、問題の早期発見に繋がり、問題を発生させた変更もすぐに特定できます。Actionsでパッケージを作成すると開発者はパッケージを署名、アップロードするだけでよくなるので、毎月発生したパッケージ作成時間をなくし、その時間を別の作業に充てることができます。Actionsで行うようにしました。この記事は、その過程で得た知見を共有するために記載しています。Actionsの使い方について記載します。ActionsのアクションはYAML形式で記述します。YAML形式なので、GitHub上でコードとして管理できます。ここからは、Groongaのパッケージ作成のアクションを例に説明していきます。Groongaのパッケージ作成のアクションは、以下の場所にあります。何のイベントをトリガーにしてアクションを実行するかを決めるには、on:を使います。Groongaのアクションではpush毎にアクションが実行されてほしいので、on:にはpushを指定します。Actionsでは、イベントが起こった対象を指定することができます。上記のように定義すると、リポジトリーのどのブランチ、タグにpushされてもアクションが実行されます。全てのブランチやタグが対象ではなく、特定のブランチ、タグにpushされたときだけアクションを実行したい場合は以下のようにします。tagpush等のイベントトリガーではなく、定期的に実行したいアクションがあるケースもあります。その場合には、schedule:を使用します。schedule:の書式はcronの書式で指定できます。ここで指定した時刻はUTCなので、UTCと時差がある日本の場合は時差を考慮に入れて設定する必要があることに注意してください。Groongaでは以下のように設定し、毎朝9時にアクションが実行されるようにしています。*onに指定できるイベントは他にもあり、以下のページにまとまっているので、必要に応じて参考にしてください。実行するアクションはjobs:という単位で定義できます。複数のジョブを作成してそれぞれ並列に実行することもできますし、あるジョブの完了を待ってから実行するというようにジョブ同士の依存関係を定義することもできます。Groongaでは、現状、パッケージを作成するというアクションのみを行っていますので、以下のようにbuildというジョブを1つだけ定義しています。build:ジョブの中ではいくつかのステップに分けてアクションを定義します。Actionsのジョブはステップごとに成功、失敗を表示するので、ジョブをステップに分割しておくと、ジョブが失敗したときの原因特定が容易になります。Groongaでは、パッケージ作成を以下のステップに分割して実行しています。依存パッケージの配置aptを用いたインストールpip3を用いたインストール(ドキュメントビルド用に使うSphinxをインストールしています)パッケージのビルドに必要なソースコードをCloneconfigureの生成ソースアーカイブ作成用にconfigure実行ソースアーカイブをビルドdebian/changelogの更新Docker上でパッケージをビルドビルドされた成果物をGitHubへアップロード具体的には以下のように定義しています。name:で分割したステップに名前をつけます。run:で実行するアクションを定義します。}}どのOSでアクションを実行するかはruns-on:で指定します。Groongaではruns-on:ubuntu-latestと定義して、Ubuntuの最新版でアクションが実行されるようにしています。Serverの最新版)やmacos-latestなどがサポートされています。実行するコマンドはruns-on:で定義したOSに応じて定義する必要があります。Ubuntuでアクションを実行する場合は、デフォルトでBashが使われるので、Bashで実行できるコマンドを使って定義していますwindows-latestを指定した場合は、デフォルトでアクションがPowerShellで実行されるので、アクションはPowerShellで実行できるコマンドで定義する必要があります。(コマンドプロンプトを使うように指定することもできます。)アクションを実行するシェルの指定については、以下のページにも説明があるので、必要に応じて参照してください。Actionsでは、よくある処理をまとめて公開共有することが可能で、それらの処理はsteps:の中で呼び出せます。Groongaでは、リポジトリからソースコードをチェックアウトするのにactions/checkoutを、ビルドしたパッケージをアップロードするのにactions/upload-artifactを使用しています。actions/checkoutは@以下にチェックアウトしたいタグやブランチを指定することができます。actions/checkout@masterと指定しています。actions/checkoutやactions/upload-artifact以外にも様々な処理がactionとして以下のURLで公開されています。https://github.com/marketplace?type=actions複数の環境でアクションを実行する複数の環境(複数のOSであったり、ソフトウェアの複数のバージョン)に対して同じアクションを実行したいケースがあります。それぞれの環境用にワークフローを定義しても良いのですが、同じアクションが複数のワークフローにあると、修正漏れが発生しやすくなってしまい、メンテナンスが煩雑になります。同じアクションを複数の環境で実行したい場合は、matrix:という定義が使えます。6,7,8)に対して同じアクションを実行しています。具体的には以下のように定義しています。packages/yum/repositories/strategy:の中にmatrix:を定義します。matrix:の中に変数を定義してそれをsteps:の中で${{matrix.xx.xx}}の形で参照できます。}}を参照して各OSごとのパッケージをアップロードできるようにしています。}}は、packages/apt/repositories/とpackages/yum/repositories/配下のファイルをアップロードしていることになります。Actionsを使ったパッケージ作成の自動化の方法について記載しました。Actionsに興味はあるが、使っていないという方は、この記事に記載されている内容を参考にして自身のプロジェクトで使用してみてはいかがでしょうか。4.0とGFDLのデュアルライセンスで自由に利用できます。クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。クリアコードは「クリアコードをいい感じにする人」を1名募集しています。クリアコードはフリーソフトウェア開発で培った技術力を提供しています。Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。