「GitHubActions」の記事 - Crieit

GitHub ActionsでEACCES: permission deniedが出るとき

2022-02-21T21:08:44+09:00

GitHub Actionsでnpx prisma generateを実行するとEACCES: permission deniedというエラーが出て全然うまくいかない。

ためしに yarn prisma generate とすると動いた。npxだとユーザーかなにかが違う…？

GitHub ActionsでJestを叩くときのタイムゾーンと言語を設定する

2021-08-30T17:14:25+09:00

GitHub リポジトリにプッシュした時、GitHub Actions のワークフローで自動的に Jest を走らせるようにしています。GitHub 上で自動的に走る Jest と、手動で直接叩く Jest との違いはタイムゾーンとロケールです。ここでは、GitHub 上で Jest を動かすときに環境変数としてタイムゾーンとロケールを指定する方法について説明します。

1. package.json にグローバル設定ファイルを指定する

以下のように設定を追記します。jest-global-setup.jsに設定を記載すれば、環境変数から読み込まれた値を上書きできます。

  "jest": {
    "globalSetup": "./jest-global-setup.js"
  },

2. jest-global-setup.js の中身を記載する

タイムゾーンと言語を指定します。

module.exports = async () => {
  process.env.TZ = "Asia/Tokyo";
  process.env.LANG = "en_US.UTF-8";
};

3. 動作結果を確認する

Jest のテストで出力される日時の文字列を確認したところ、言語が日本語から英語になっていることが確認できました。

    -     "date": "Wed Apr 01 2020 09:00:00 GMT+0900 (日本標準時)",
    +     "date": "Wed Apr 01 2020 09:00:00 GMT+0900 (Japan Standard Time)",

📝 Node.js パッケージを公開するための GitHub Actions を構築する

2021-06-21T22:22:57+09:00

react-emoji-textarea の開発を行った際、リリースを作成したら自動的に Node.js パッケージにライブラリが公開される仕組みがほしいと考え、GitHub Actions でそれを実現することにしました。

その際、公式サイトに公開されている内容を参考に GitHub Actions を作成したのですが、そのまま利用すると私の環境では下記のエラーが発生してしまいました。

error Couldn't publish package: "https://registry.yarnpkg.com/@nikaera/react-emoji-textarea: You do not have permission to publish \"react-emoji-textarea\". Are you logged in as the correct user?"

上記のエラーについて調査しながら改修したところ、最終的に下記の GitHub Actions で Node.js パッケージを公開できるようになりました。secrets.NPM_TOKEN には NPM Token を登録します。

# package.yml
name: Node.js Package
on:
  # workflow_dispatch を追加して手動でも実行できるよう改修
  workflow_dispatch:
  release:
    types: [created]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "14.x"
          registry-url: "https://registry.npmjs.org"
          # registry.npmjs.org へアクセスする際は必ず認証を試みるオプションを追加
          always-auth: true
          # scope には自分のユーザ名を指定
          scope: "@nikaera"
        # .npmrc に https://registry.npmjs.org アクセス時に利用する認証情報を記載する
      - run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
      - name: Build react-emoji-textarea 😆💖
        run: |
          yarn install --frozen-lockfile
          yarn format
          yarn build
      - run: yarn publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

GameCI で Unity の CI 環境を GitHub Actions で構築する

2021-05-26T22:30:30+09:00

はじめに

先日同僚が Unity の CI 環境を構築するためのライブラリである GameCI について教えてくれました。早速 GameCI の GitHub Actions を利用して、サンプルプロジェクトで色々動作検証してみたところ、Unity の CI 環境を楽に構築できることが分かりました。

もちろん、Unity Cloud Build を利用すれば CI 環境の構築は以前から楽にできました。しかし、選択肢の 1 つとして GameCI を持っておくことで、サクッと GitHub Actions に統合する形で Unity の CI 環境を導入できるのは他には無いメリットを感じました。

本記事で紹介しているソースコード、及び検証時に利用したプロジェクトは GitHub にアップ済みですので、手っ取り早く内容を把握されたい方は下記をご参照くださいませ。

https://github.com/nikaera/Unity-GameCI-Sample

業務でも利用できそうなので、GameCI を利用して CI 環境を構築する手順を記事でまとめました。

GameCI に備わっている機能紹介

GameCI には現状下記の GitHub Actions が用意されているようです。

機能	概要
Activation	Unity ライセンスを任意の Unity バージョンで発行する
Test runner	Unity の PlayMode 及び EditMode のテストを実行する (テスト結果の出力にも対応)
Builder	任意の Platform ビルドを実行する (アーティファクト利用でダウンロードも可能)
Returning a license	Unity ライセンスの返却ができる (Professional License のみ対応)
Remote builder	GitHub Actions のスペックでは満足のいくビルドができない際に AWS 環境でハイスペックなマシンを用意してビルドできる。ビルドのためのインフラ構築には AWS CloudFormation を使用している (現在は AWS のみ対応。今後 GCP, Azure にも対応予定とのこと)
Deployment	Unity ビルドを各種 Platform 向けにデプロイする (iOS 及び Android のみ記載あり。厳密に言うと `Builder` でビルド出力した内容を `fastlane` を用いてデプロイするためのワークフロー紹介になっている)

上記を見ると既に GameCI には開発者として Unity CI に欲しい機能は最低限揃っているように見受けられました。 また本記事では、今後機会があれば試してみたいと考えていますが Remote builder 及び Deployment については言及していません。

今回は実例を交えながら Activation 及び Test runner、Builder、Returning a license の使用方法について紹介していきます。

Activation: GameCI で必要となる Unity License のアクティベーションを行う

GameCI で Unity ライセンスをアクティベートするには Activation を利用します。早速ドキュメントの手順に沿って作業を進めていきます。

まず CI を導入したい GitHub 上の Unity プロジェクトの .github/workflows 内に Unity ライセンスアクティベート用のワークフローファイルを作成します。

# .github/workflows/activation.yml
name: Acquire activation file
on:
  workflow_dispatch: {}
jobs:
  activation:
    name: Request manual activation file 🔑
    runs-on: ubuntu-latest
    steps:
      # GameCI の Activation を利用して alf ファイルを発行する
      - name: Request manual activation file
        id: getManualLicenseFile
        uses: game-ci/unity-request-activation-file@v2
        with:
          # Unity プロジェクトのバージョンを指定する
          # ProjectSettings/ProjectVersion.txt に記載されているバージョンを入力すれば OK
          unityVersion: 2020.3.5f1
      # Upload artifact (Unity_v20XX.X.XXXX.alf)
      - name: Expose as artifact
        uses: actions/upload-artifact@v2
        with:
          name: ${{ steps.getManualLicenseFile.outputs.filePath }}
          path: ${{ steps.getManualLicenseFile.outputs.filePath }}

その後、デフォルトブランチにプッシュして GitHub Actions で実行可能にしたら、下記手順に従い Unity ライセンスファイルのアクティベート及びダウンロードを行います。

alf ファイルを生成する" />
1. ブラウザから GitHub リポジトリにアクセスして、Unity ライセンスアクティベート用のワークフローを実行して alf ファイルを生成する

2. ワークフローの実行に成功したら、該当項目をクリックして詳細画面に遷移する

Artifacts の項目から alf ファイルをダウンロードする" />
3. Artifacts の項目から alf ファイルをダウンロードする

alf ファイルをアップロードする" />
4. Unity license manual activation webpage からログインして alf ファイルをアップロードする

5. Unity ライセンスの利用用途に応じて適切な選択肢を入力する (本記事では Personal ライセンスを選択)

Download license ボタンをクリックして ulf ファイルをダウンロードする" />
6. Download license ボタンをクリックして ulf ファイルをダウンロードする

これで Unity ライセンスファイルのアクティベートは完了です。次にアクティベートしたライセンスファイルを GitHub リポジトリの Secrets に登録して、GameCI で PlayMode 及び EditMode のテストが実行できるようにしていきます。

alf 拡張子のファイルがライセンスリクエストファイルを指していて、Unity ライセンスの発行に必要となるファイルです。ulf 拡張子のファイルが Unity ライセンスのファイルです。¹

Test runner: PlayMode 及び EditMode テストを実行して結果を参照する

GitHub Actions 上でテストを実行するために、先ほどアクティベートした Unity ライセンスの情報をワークフロー上で扱えるようにする必要があります。そのため、まずは Secrets に ulf ファイルの内容を登録することから始めます。

Secrets 登録画面に遷移する" />
1. Unity ライセンスの情報登録のため、Github リポジトリの Secrets 登録画面に遷移する

Secrets の UNITY_LICENSE を参照する。そのため、Name を UNITY_LICENSE で Value に ulf ファイルの中身をコピー & ペーストしておく" />
2. GameCI はライセンス情報参照のため、デフォルト設定では Secrets の UNITY_LICENSE を参照する。そのため、Name が UNITY_LICENSE、Value には ulf ファイルの中身を登録する²

上記作業で GameCI でテストやビルド実行を行える環境が整ったので、動作検証のためテスト実行用のワークフローファイルを作成します。

# .github/workflows/test.yml
name: Run EditMode and PlayMode Test
on:
  workflow_dispatch: {}
jobs:
  test:
    name: Run EditMode and PlayMode Test
    runs-on: ubuntu-latest
    steps:
      # actions/checkout@v2 を利用して作業ディレクトリに
      # Unity プロジェクトの中身をダウンロードしてくる
      - name: Check out my unity project.
        uses: actions/checkout@v2

      # GameCI の Test runner を利用して
      # EditMode 及び PlayMode のテストを実行する
      - name: Run EditMode and PlayMode Test
        uses: game-ci/unity-test-runner@v2
        env:
          # 2. の手順で Secrets に登録した Unity ライセンスの情報を指定する
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

          # もし Professional license を使いたい場合は、
          # メールアドレス、パスワード、シリアルナンバーを入力する必要がある
          # ref: https://game.ci/docs/github/test-runner#professional-license
          # UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          # UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
          # UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}
        with:
          projectPath: .
          # テストの実行結果もみたい場合は githubToken を指定する
          # secrets.GITHUB_TOKEN は Secrets 未登録でも利用可能
          githubToken: ${{ secrets.GITHUB_TOKEN }}

          # Unity プロジェクトのバージョンを指定する
          # ProjectSettings/ProjectVersion.txt に記載されているバージョンを入力すれば OK
          unityVersion: 2020.3.5f1

          # 実行したいテストの種類を指定できる
          # 指定可能な値は All, PlayMode, EditMode
          # testMode: All

          # テスト実行時に利用したい Docker イメージを明示的に指定できる
          # customImage: 'unityci/editor:2020.1.14f1-base-0'

      # テストの実行結果をアーティファクトにアップロードしてダウンロードして参照できるようにする
      - uses: actions/upload-artifact@v2
        if: always()
        with:
          name: Test results
          path: artifacts

上記のワークフローファイルを GitHub Actions 上で動作検証する際の手順は下記になります。

1. Unity のテストを実行するためのワークフローを選択して実行する

Test Results の項目からテストの実行結果を確認する" />
2. ワークフローの実行が成功したら、詳細画面に遷移した後、Test Results の項目からテストの実行結果を確認する

テスト実行用のワークフローファイルでは workflow_dispatch で実行可能にしていますが、pull_request を利用すればプルリク時にテストを実行させることが可能になります。

Builder: プロジェクトのビルドを実行して出力結果を確認する

GameCI にはプロジェクトのビルドを行うための GitHub Actions も用意されています。実際に GameCI で WebGL ビルドを行いその内容を GitHub Pages で確認できるようにして動作検証していきます。

早速 WebGL ビルドを行うためのワークフローファイルを作成していきます。

# .github/workflows/webgl_build.yml
name: Run the WebGL build
on:
  workflow_dispatch: {}
jobs:
  build:
    name: Run the WebGL build
    runs-on: ubuntu-latest
    steps:
      # actions/checkout@v2 を利用して作業ディレクトリに
      # Unity プロジェクトの中身をダウンロードしてくる
      - name: Check out my unity project.
        uses: actions/checkout@v2

      # GameCI の Builder を利用して、
      # Unity プロジェクトのビルドを実行する
      - name: Run the WebGL build
        uses: game-ci/unity-builder@v2
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
        with:
          # 今回は WebGL ビルドを行いたいため WebGL を指定する
          # WebGL 以外の指定可能な値は下記に記載の値が利用可能
          # ref: https://docs.unity3d.com/ScriptReference/BuildTarget.html
          targetPlatform: WebGL

          unityVersion: 2020.3.5f1
      # Builder で出力した WebGL ビルドを GitHub Pages にデプロイする
      - name: Deploy to GitHub Pages
        uses: JamesIves/[email protected]
        with:
          # GitHub Pages デプロイ用の Orphan ブランチ名を指定する
          branch: gh-pages

          # デプロイ用ビルドフォルダパスを指定する
          # GameCI の Builder はデフォルトでは build フォルダにビルド内容を出力する
          folder: build

      # Builder で出力した WebGL ビルドをアーティファクトでダウンロード可能にする
      - name: Upload the WebGL Build
        uses: actions/upload-artifact@v2
        with:
          name: Build
          path: build

上記のワークフローファイルを GitHub Actions 上で動作検証する際の手順は下記になります。

1. Unity の WebGL ビルドを実行するためのワークフローを実行する

2. ワークフローの実行が成功したら、詳細画面に遷移した後、ビルド内容が正常そうか確認する

3. ビルド内容を確認するための GitHub Pages の設定を Settings から行う

4. GitHub Pages でブラウザから WebGL ビルドの動作確認をする

上記のように Builder を利用することで WebGL ビルドの成否及び、最新のビルド内容を常に GitHub Pages で見られるようにできます。 すると WebGL ビルドが正常かどうかの確認が常に GitHub Pages を見れば把握できるようになるため、Unity1 週間ゲームジャムなどに参加する際で便利に活用できそうです。

WebGL ビルドを行う際、Unity バージョンやアセットの対応状況によっては正しくブラウザ上で動作しないビルドが出力されます。ただし、ブラウザで発生するエラー内容によっては WebGL のビルド設定を見直すだけで解決できる場合があります。 例えば unityframework is not defined というエラーが発生した際は、この記事のように WebGL の Build Settings を見直すことで解決できる場合があります。

私の環境では JamesIves/github-pages-deploy-action で GitHub Pages へのデプロイを行った際、デフォルトでは /WebGL/WebGL フォルダにビルド内容が出力されました。そのため、ブラウザから WebGL ビルドにアクセスする際、/WebGL/WebGL のような URL にアクセスする必要がありました。

Returning a license: GameCI で利用している Unity License を返却する

通常利用することは無いと公式サイトにも書かれていますが、Professional License の返却も GameCI で行うことが可能です。 今回は Personal License を利用したため使用しませんでしたが、下記をワークフローのステップに組み込むことで Professional License を返却できるようです。

# ...
# どこかのタイミングでライセンスのアクティベートを行う
- name: Activate Unity
  uses: game-ci/unity-activate@v1
  env:
    UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

#...
# ステップの最後などに game-ci/unity-return-license@v1 を呼び出して
# アクティベート済みのライセンスを返却する
- name: Return license
  uses: game-ci/unity-return-license@v1
  if: always()
  #...

おわりに

以前 Unity コマンドを駆使して自分で CI 環境を構築した経験があるのですが、
GameCI を利用した方が全然楽に Unity CI 環境構築を GitHub Actions 上で行えました。

ちなみに GameCI で利用されている Docker イメージは以前からよく使われていた gableroux/unity3d が元になっているようでした。ってか GabLeRoux さんのホームページを見たら、GameCI の開発を始めた方のようでした。すごい。

本記事が GitHub Actions で Unity CI 環境構築を始めようとしている方の助けになれれば幸いです。

参考リンク

alf ファイル及び ulf ファイルの実態は XML ファイルです。 ↩︎
適当なテキストエディタで ulf ファイルを開き全文をコピー & ペーストします。 ↩︎

Zenn の記事を DEV に自動的に同期させる GitHub Action 作ってみた

2021-03-22T13:21:27+09:00

はじめに

去年 DEV のアカウントを作成したものの、今まで全く有効活用出来ていませんでした。

DEV にはカノニカル URL を設定出来るので、常々 Zenn の記事を投稿する際にクロスポストしたいなと考えておりました。そこで、Zenn に記事を投稿したら、自動的に DEV にも記事を投稿 & 同期する GitHub Action を作ってみました。
sync-zenn-with-dev-action

今回初めて GitHub Action を自作したのですが、その中で得た知見を残す形で記事を書くことにしました。また、GitHub Action は TypeScript で作成しました。

開発した GitHub Action の概要

まずはザッとどのような GitHub Action を作成したのか、概要について説明いたします。

GitHub リポジトリで管理している Zenn の記事を DEV に同期して投稿する GitHub Action を作成しました。 その際に DEV へ投稿する記事には Zenn の該当記事へのカノニカル URL も自動で設定できます。これにより DEV と Zenn へ記事をシームレスにクロスポストすることが可能となります。

今回作成した GitHub Action を利用するワークフローファイルの一例は下記となります。

name: "Sync all Zenn articles to DEV"
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout my project
        uses: actions/checkout@v2
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        # id を設定することで、後のジョブで Output で指定した値が参照可能になる
        id: dev-to
        with:
          # DEV の API キーを指定する
          api_key: ${{ secrets.api_key }}
          # (オプション) DEV に記事を投稿した際に Zenn のカノニカル URL を設定したい場合に指定する
          # username: nikaera
          # (オプション) 改行区切りで指定した articles フォルダ内のファイルパスを記載した txt ファイルを指定することで、記載された記事のみを同期するようになる。
          # 他プラグインと組み合わせることで差分のみを txt ファイルに載せることが可能。詳細については後述の Outputs の項目に記載。
          # added_modified_filepath: ./added_modified.txt
          # (オプション) Zenn の articles 以下全ての記事を常に DEV に同期するか指定する
          # update_all が true のときは added_modified_filepath は無視される。
          # update_all: false
        # 上記アクション実行時に DEV に新規で同期する記事に関しては Zenn のマークダウンヘッダに
        # 該当する DEV の記事の ID が dev_article_id として記載されるようになる。
        # 今後はその ID を元に同期するようになるため、該当する Zenn の記事をコミットする。
        # 新規で同期する記事が無ければ、このジョブは実行しない。
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
        # Outputs には DEV の記事情報 (title, url) が含まれるようになるため、
        # 最後に出力して実行結果の内容を確認することもできる
      - name: Get the output articles.
        # dev-to という id が紐付いたジョブの Outputs を取得して echo で内容を出力する
        run: echo "${{ steps.dev-to.outputs.articles }}"

簡単に nikaera/sync-zenn-with-dev-action@v1 というジョブの内部処理について説明いたします。

Inputs の update_all 及び added_modified_filepath で受け取った情報を元に、
どの記事を DEV に同期させるか判定する
DEV に同期する記事のファイルパス一覧を取得して、
それぞれの記事のヘッダに dev_article_id の記載があるか判定する
Inputs の api_key を利用して、Zenn の記事に dev_article_id が含まれていれば、
該当する DEV の記事を更新する。含まれていなければ DEV に新規で記事を作成する
Inputs の username を利用して、
DEV の記事に該当する Zenn 記事のカノニカル URL を設定する
DEV に新規で記事を作成した場合は、
Zenn の該当記事のヘッダに dev_article_id を書き込む
DEV に記事を投稿する際、Zenn は対応しているが、
DEV では対応していない記述は削除する (::: 記法や一部のコード記法)
記事の公開ステータス及びタグなどについても DEV の記事に反映する¹
新規で DEV に記事を同期した Zenn 記事のファイルパスを、
Outputs の newly-sync-articles に設定する
(後のジョブで dev_article_id の含まれた記事をコミットしたいため)
ワークフローで同期された記事情報は Outouts の articles に設定する

Inputs と Outputs の内容一覧については下記になります。

Inputs

キー	説明	必須
api_key	DEV の API Key を設定する	o
username	Zenn の自分のアカウント名を設定する (DEV に同期する記事に Zenn のカノニカル URL を設定したい場合のみ)	x
added_modified_filepath	改行区切りで指定した articles フォルダ内のファイルパスを記載した txt ファイルを指定することで、記載された記事のみを同期するようになる。PR やコミット差分のファイルのみを取得するための GitHub Action jitterbit/get-changed-files@v1 と組み合わせることで、更新差分のあった記事のみを随時同期することも可能。² 更新差分のあった記事のみを随時同期するための実際のワークフローファイルはこちら	x
update_all	Zenn の全ての記事をどうきするかどうかを設定する。GitHub Action 初回実行時のみ true にする使い方を想定している。デフォルトは true。`added_modified_filepath` よりも `update_all` が優先されるため `added_modified_filepath` を設定する場合は false を設定する必要あり`	x

Outputs

キー	説明
articles	同期された DEV の記事のタイトル及び URL が格納された配列
newly-sync-articles	DEV で新たに新規作成された Zenn 記事のファイルパスが格納された配列。実際のワークフローファイルの該当する記述のように、必ずコミットに含めるようにする必要がある (理由は後述)

Inputs 及び Outputs については公式サイトの説明をご参照ください。

Zenn の記事を DEV に同期するための仕組み

Zenn の記事を新規で DEV に同期する際は、DEV に記事を新規作成する必要があります。その際に Zenn の記事と DEV の記事を紐付けるための何らかの仕組みが必要となります。そうしないと、今後 Zenn の記事内容を更新した際に、DEV のどの記事に内容を同期させればよいかが不明なためです。

そこで、記事を同期するための仕組みとして、dev_article_id というフィールドを Zenn のマークダウンヘッダに追記することで DEV の同期すべき記事との紐付けを行うことにしました。dev_article_id には DEV の記事作成 API 実行時の返り値である id を設定します。

一度 id を dev_article_id として Zenn の記事に紐付けてしまえば、次回以降に記事の同期を行う際は DEV の記事更新 API を利用できます。

また、Outputs の newly-sync-articles には新規で作成された DEV 記事の id である dev_article_id が追記された Zenn 記事のファイルパスが格納されています。そのため、nikaera/sync-zenn-with-dev-action@v1 実行後は、下記のように steps.dev-to.outputs.newly-sync-articles 内に格納されたファイル群をコミットに反映させる必要があります。

# `nikaera/sync-zenn-with-dev-action@v1` 実行後に必ず定義すべきジョブ
# DEV に新規に作成した記事がなければ実行しない (if: steps.dev-to.outputs.newly-sync-articles)
- name: write article id of DEV to articles of Zenn.
    run: |
        git config user.name github-actions
        git config user.email [email protected]
        git add ${{ steps.dev-to.outputs.newly-sync-articles }}
        git commit -m "sync: Zenn with DEV [skip ci]"
        git push
    if: steps.dev-to.outputs.newly-sync-articles

上記のジョブで newly-sync-articles に格納された dev_article_id が追記された Zenn 記事は随時コミットに反映しないと、Zenn の全ての記事が同期毎 DEV に新規作成され続けるという不具合を引き起こしてしまうので、ご注意ください

GitHub Action を開発する手順

サクッと開発に取り組みたかったため、Docker コンテナを利用する方法ではなく、JavaScript を利用する方法で開発を進めていくことにしました。

TypeScript で GitHub Action を作る

GitHub 公式が TypeScript で GitHub Action を作るためのテンプレートプロジェクトを用意してくれています。今回はこのテンプレートプロジェクトを利用する形でプロジェクトを作成しました。

(余談) GitHub Action では Docker コンテナを用いてワークフローを実行可能です。そのため、実行環境は自由に設定出来ます。(Go, Python, Ruby, etc.)

早速 TypeScript のテンプレートプロジェクトを元に自分の GitHub Action プロジェクトを作成します。

1. テンプレートプロジェクトを元に GitHub Action の TypeScript プロジェクトを作成する

2. プロジェクトの作成後 git clone してきて開発する準備を整える

GitHub Action プロジェクトの開発を進めるための準備を行う

テンプレートプロジェクトを git clone したら、まずは action.yml の内容を変更します。
今回作成した GitHub Action の action.yml は下記となっております。

# action.yml
# GitHub Action のプロジェクト名
name: 'Sync Zenn articles to DEV'
# GitHub Action のプロジェクト説明文
description: 'Just sync Zenn articles to DEV.'
# GitHub Action の作者
author: 'nikaera'
# GitHub Action に渡せる引数の値定義
inputs:
  api_key:
    # フィールドの指定が必須であれば true、必須でなければ false を設定する
    # DEV の API キーは同期を行う際に必須なため、true を設定している
    required: true
    # フィールドの説明文
    description: 'The api_key required to use the DEV API (https://docs.forem.com/api/#section/Authentication)'
  username:
    required: false
    description: "Zenn user's account name. (Fields to be filled in if canonical url is set.)"
  articles:
    required: false
    description: "The directory where Zenn articles are stored."
    # フィールドにはデフォルト値を指定することも可能
    # Zenn の記事がデフォで格納されているフォルダ名を指定している
    default: articles
  update_all:
    require: false
    description: "Whether to synchronize all articles."
    default: true
  added_modified_filepath:
    required: false
    description: |
      Synchronize only the articles in the file path divided by line breaks.
      You can use jitterbit/get-changed-files@v1 to get only the file paths of articles that have changed in the correct format.
      (https://github.com/jitterbit/get-changed-files)
# GitHub Action 実行後に参照可能になる値定義
outputs:
  articles:
    description: 'A list of URLs of dev.to articles that have been created or updated'
  newly-sync-articles:
    description: 'File path list of newly synchronized articles.'
# GitHub Action の実行環境
runs:
  using: 'node12'
  # テンプレートプロジェクトでは コンパイル先が dist になるため `dist/index.js` を指定している
  main: 'dist/index.js'

TypeScript のテンプレートプロジェクトでは、バンドルツールとして ncc が採用されています。GitHub Action 実行時に使用されるのは ncc によりコンパイルされた単一の JavaScript ファイル (dist/index.js) になります。

あとは src フォルダ内でプログラムを書いて、npm run all && node dist/index.js のようにコマンド実行しながら開発を進めていくだけです。

(余談) GitHub Action の開発ツールとして Docker を利用した act というものが存在するようです。ローカル環境で検証する際は既知の問題に対応する必要がありそうですが、GitHub Action の開発で非常に有効活用できそうで気になっております。

今回の開発では利用しなかったのですが、今後開発を進めていく中で利用する機会も出てきそうなので、その際は本記事内容を更新する形で知見を追記したいと考えております。

:::

GitHub Action を実装する際に利用した機能

GitHub Action を実装する際に利用した機能を、実際のコード内容を抜粋して簡単に説明していきます。下記で紹介する内容は GitHub Actions Toolkit の機能です。

/**
下記の yml の with で指定した値は core.getInput で受け取ることが可能。

- name: dev.to action step
    uses: nikaera/sync-zenn-with-dev-action@v1
    id: dev-to
    with:
        # DEV の API キーを指定する
        api_key: ${{ secrets.api_key }}
*/
core.getInput("api_key", { required: true });
core.getInput("update_all", { required: false });

/**
下記の yml の steps.<ジョブで指定した id>.outputs で参照可能な値をセットすることが可能。
セットする内容は文字列である必要がある。

- name: dev.to action step
    uses: nikaera/sync-zenn-with-dev-action@v1
    id: dev-to
- name: Get the output articles.
    run: echo "${{ steps.dev-to.outputs.articles }}"
*/

core.setOutput("articles", JSON.stringify(devtoArticles, undefined, 2));
core.setOutput("newly-sync-articles", newlySyncedArticles.join(" "));

/**
GitHub Action 実行時に出力されるログをレベルごとに出力することが可能
core.debug はローカル実行時のみに出力内容を確認することができる
*/
core.debug("debug");
core.info(`update_all: ${updateAll}`);
core.error(JSON.stringify(error));

上記だけ把握してれば GitHub Action の開発は問題なく行うことができました。

作成した GitHub Action を実際に GitHub 上で実行可能にする

ローカル環境で一通り開発が完了したら、GitHub リポジトリに push した後タグ付けを行います。GitHub Action はタグを設定しないと実行できないため必要な作業となります。 今回タグ付けは GitHub 上で行いました。

1. タグの項目をクリックする

2. Create a new release ボタンをクリックしてタグ作成画面に遷移する

3. Publish release ボタンをクリックしてタグの作成を完了する

上記の例では v1 というタグを作成したので nikaera/sync-zenn-with-dev-action@v1 のような記述で GitHub Action を利用可能になりました。 私は Zenn の記事を zenn.dev というリポジトリで管理しているため、早速このリポジトリに GitHub Action を導入してみます。

Zenn の全ての記事を DEV に同期するためのワークフロー

本記事の GitHub Action では DEV の API キーを使用するため、事前にシークレットへ API_KEY という名称で値を登録しておきます。公式サイトの手順に従いシークレットの登録が完了したら、該当リポジトリに .github/workflows/sync-zenn-with-dev-all.yml というワークフローファイルを作成します。

# .github/workflows/sync-zenn-with-dev-all.yml
name: "Sync-All Zenn with DEV"
on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.message, '[skip ci]') == false
    steps:
      - name: setup node project
        uses: actions/checkout@v2
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        id: dev-to
        with:
          api_key: ${{ secrets.api_key }}
          # Zenn の自分のアカウント名を指定すると
          # DEV 記事のカノニカル URL に Zenn 記事の URL を指定できる
          # username: nikaera
          update_all: true
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
      - name: Get the output articles.
        run: echo "${{ steps.dev-to.outputs.articles }}"

上記は手動実行が可能な Zenn の記事を全て DEV に同期するためのワークフローファイルになります。作成が完了したらワークフローファイルを実行して、記事が正常に同期できているか確認してみます。

1. Actions タブをクリックする

2. 作成した Sync-All Zenn with DEV ワークフローファイルを選択する

3. Run workflow ボタンを実行して、ワークフローを実行する

4. ワークフローの実行が正常に完了していれば、ログに DEV の記事情報が出力される

5. dev.to にアクセスして Zenn の記事情報が正常に同期されていることを確認する

正常に Zenn の全ての記事が DEV に同期されていることが確認できたら、次は Zenn の記事が新規作成されたり、更新されたときのみに DEV に同期するためのワークフローファイルを作成します。

更新差分のあった Zenn 記事のみを DEV に同期するためのワークフロー

main ブランチが更新されたときのみ更新された記事のみを DEV に同期するためのワークフローファイルを作成します。該当リポジトリに .github/workflows/sync-zenn-with-dev.yml というワークフローファイルを作成します。

# .github/workflows/sync-zenn-with-dev.yml
name: "Sync Zenn with DEV"
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.message, '[skip ci]') == false
    steps:
      - name: setup node project
        uses: actions/checkout@v2
      - name: get modified files
        id: files
        uses: jitterbit/get-changed-files@v1
      - name: output modified files to text
        run: |
          for changed_file in ${{ steps.files.outputs.added_modified }}; do
            echo "${changed_file}" >> added_modified.txt
          done
      - name: dev.to action step
        uses: nikaera/sync-zenn-with-dev-action@v1
        id: dev-to
        with:
          api_key: ${{ secrets.api_key }}
          # Zenn の自分のアカウント名を指定すると
          # DEV 記事のカノニカル URL に Zenn 記事の URL を指定できる
          # username: nikaera
          added_modified_filepath: ./added_modified.txt
          update_all: false
      - name: write article id of DEV to articles of Zenn.
        run: |
          git config user.name github-actions
          git config user.email [email protected]
          git add ${{ steps.dev-to.outputs.newly-sync-articles }}
          git commit -m "sync: Zenn with DEV [skip ci]"
          git push
        if: steps.dev-to.outputs.newly-sync-articles
      - name: Get the output articles.
        run: echo "${{ steps.dev-to.outputs.articles }}"

上記ワークフローファイルの作成が完了したら、早速動作確認のために、まさに今執筆中の本記事内容をリポジトリに push してみます。

1. git push 後に該当するワークフローの実行結果を確認する

2. dev.to に執筆途中の内容で記事が同期されていることを確認する

これまで説明してきた 2 つのワークフローを利用することで、大抵のユースケースはカバーできるはずです。

おわりに

GitHub Action の勉強のために取り組んだプロジェクトですが、思いの外楽しくて他にも色々な機能のアイデアがあるので随時実装していきたいと考えています。(英訳, タイトルフォーマット変更, etc.)

DEV に Zenn の記事をクロスポストする GitHub Action を公開することで、いつもお世話になっている Zenn というプラットフォームを海外の方に認知していただける機会を創出できたのかもと考えたらテンションが上がってきました。

それはさておき、Zenn の記事を他でも有効活用するための GitHub Action を開発する際には、恐らく本記事で紹介した GitHub Action のコードが参考になるはずです。

また、GitHub Action の Marketplace というものが用意されているようなので、開発がある程度完了次第、こちらに申請するのも試してみたいと考えております。

ところで、Crieit さんにも記事投稿 API ができたらクロスポストできるようにしたいな...という個人的願望がありますｗ

参考リンク

DEV (Forem) の仕様上、タグは最大でも 4 つまでしか設定できないため、Zenn で設定したタグの先頭 4 つまで DEV の記事には設定しています ↩︎
当然といえば当然ですが jitterbit/get-changed-files@v1 は workflow_dispatch でワークフローを手動実行した際や、force push 等でファイル差分を正確に特定できない操作には対応しておりませんので、その場合はエラーが発生します ↩︎

Netlifyのビルド時間をGitHub Actionsで0時間にして月末のヒヤヒヤから解放されよう！

2021-02-20T15:13:23+09:00

Netlifyのビルド時間をGitHub Actionsで0時間にして月末のヒヤヒヤから解放されよう！

Netlify

みなさんもご存じ超便利ありがたサービスNetlifyですが、無料で使ってる貧民には毎月とある悩みがでてきます。

今月のビルド時間は残り○○分

NetlifyはGitHubのレポジトリと連携して、フロントのビルドを実行した上で、デプロイするという超便利機能があるのですが、このビルドを回すのに時間の制約があり、

無料民だと月300分となっております。(それ以上はPro版月19ドル課金すれば問題なく使えます。課金も経験済み)

300分あれば大丈夫そう、とそう思う気もしなくなくもないですが、

複数レポジトリにわたってNetlifyを使っていたり、Gatsby.jsで画像をたくさん使っていてSharpの画像リサイズに時間がかかったり、Dependabotで定期的にPRが出てPreview deployが発生したりすると
案外ぎりぎりだったりします。

なので、私のような貧民は月末になると、Netlifyのビルド時間が気になってこのブログの記事を書かなくなったり、サイトリファクターのペースが落ちてしまいます。

特にブログ更新は顕著で、例えば今書いている記事も通勤の電車の中でスマホから書いているわけなので、細かくコミットを打って保存したいのですが、コミットを打ってプッシュしてしまうと、ビルドが走ることになるので、WIPでのコミットが億劫になり、結果的に家のようなまとめてプッシュできるような作業スペースがある場所でないと、
ブログを書かなくなってしまいました。

せっかくNetlify CMS化した意味がないですね。

この悩みGitHub Actionsにお任せください

ということでこの悩み、GitHub Actionsで解決してみたいと思います。

なんか工務店のCMみたいな表現になってしまいました。

Netlifyのビルド時やっていることを洗い出して自前でやってみる

基本的にNetlifyがビルド時やってることは、例えばGatsby.jsであれば、gatsby buildコマンドを実行し、特定のディレクトリー(大概は./public)に配置されたビルド済みJSをデプロイする動きなので、
それをそっくりGitHub Actionsに移行すればいいのですが、Netlifyがビルド済みJSに対して後処理(PostProcess)を実行してるパターンもあります。

私の場合、JSやイメージを最適化してくれるAsset optimizationとFormタグに属性をつければ勝手にFormを作ってくれるForm detectionの二つが設定されていましたのでそれぞれまず無効化します。

Form detectionの解説はこちらを参照ください。

こちら、Netlifyで実施してくれなくなりますので、こちらで実装し直す必要があります。

gatsby-plugin-minify

Asset optimizationのうち、JSやCSSのminiferはgatsby-plugin-minifyを使うことでhtmlやJS、CSSをminifyできます。

インストールはいつも通りNPM(yarn)から

npm install gatsby-plugin-minify

使い方はgatsby-config.jsのpluginsに次のように設定すればできます。

    {
      resolve: 'gatsby-plugin-minify',
      options: {
        caseSensitive: false,
        collapseBooleanAttributes: true,
        useShortDoctype: false,
        removeEmptyElements: false,
        removeComments: true,
        removeAttributeQuotes: false,
        minifyCSS: true,
        minifyJS: true,
      },
    },

minifyCSSとminifyJSをtrueにすることにより、CSSについてはclean-css、JSについてはUglifyJSを使って一緒にminifyされます。また、gatsby-plugin-minifyの裏側はhtml-minifierをgatsby-node.jsでpostbuildで全掛けしているだけなので、細かいオプションはhtml-minifierで設定できる感じです。

ちなみに、気を付けないといけないのがremoveAttributeQuotesのオプションをfalseにすること。

これをtrueにすると、HTMLタグ内のアトリビュートにダブルクオートが入らなくなりちょっとファイルが軽くなるのですが、berss.comのようにサイトのRSSリンクを取得するようなシステムでうまく読み込めなくなってしまい、サイト更新が最悪通知できなくなってしまう現象が発生しました。

これで1日使ってしまった...。

RSSのリンクをページのLinkとして仕込んでいる人は要注意です。

imgurを使うことで、画像ホスティングとリサイズを同時にやっちゃう

imgurというサービスがあります。

主にRedditとかGifをあげるための画像ホスティングサービスとして有名なのですが、こちらを使うことで簡単に画像のリサイズとホスティングを実現できるため、このブログではimgurを使ってます。

画像URLの後ろに画像サイズに合わせたキーワードを入れることで実現できます。

例えばこちらのURLの画像を

[https://i.imgur.com/Wfz9G0B.png](https://i.imgur.com/Wfz9G0B.png)

160x160にリサイズするには後ろにbをくっつけます。

[https://i.imgur.com/Wfz9G0Bb.png](https://i.imgur.com/Wfz9G0Bb.png)

これで、画像最適化も完了です。

getform.io

Getform.ioはフォームのバックエンドを提供するすばらしいサービスです。

便利なインテグレーションを使うには有料版が必要ですが、フォームに投稿されたら指定したメールアドレスに通知メール飛ばす、くらいのことであれば無料でできます。

これで、NetlifyのForm detectionを置き換えていきます。

まず、新しいフォームを作ると、FormのAction先URLが発行できます。

Formの作り方は下記のブログにわかりやすく纏めてあったので参照いただければと思います。

https://blog.nakamu.life/posts/getform-io

さて、Formができたらチュートリアルに沿ってそのまま、FormタグのactionにこちらのURLを設定してもいいのですが、GetFormは無料版だと、Form投稿後のThanksページが設定できません。

まぁこれでも十分なのですが、せっかくReactを使ってるので、裏側でgetform.ioのURLをPOST fetchしながら、actionsで定義した自分のThanks URLに飛ばすように指定しましょう。

まずは、FormにonSubmitを設定します。

```typescript{numberLines: 1}{5}

Your name


そして、別途にonSubmitで発火する関数を定義します。

```typescript
  handleSubmit(e) {
    e.preventDefault();
    const form = e.target;
    fetch('https://getform.io/f/xxxxxxxxxxxxxxxxxxxxxxxxx', {
      method: 'POST',
      body: Contact.encode({
        'form-name': form.getAttribute('name'),
        ...this.state,
      }),
    })
  }

Formの送信なので、fetchではFormDataに要素をappendしたものを送信しないといけません。

  static encode(data) {
    const formData = new FormData();
    // eslint-disable-next-line no-restricted-syntax
    for (const key of Object.keys(data)) {
      formData.append(key, data[key]);
    }
    return formData;
  }

繰り返しになりますがReactではFormで、actionのほか、onSubmitを関数としてすることができます。

ただし、onSubmitが押されたタイミングで、Formの入力項目をPOST Fetchで渡さないといけないので、Formの入力で発生するchangeEventごとに、Formの値をstateとして保存しておくようにします。

```typescript{numberLines: 1}{1-7,21}
handleChange(e) {
this.setState({ [e.target.name]: e.target.value });
}

handleAttachment(e) {
this.setState({ [e.target.name]: e.target.files[0] });
}

(中略)

            
               Your name


また、onSubmitを使ってしまうと、Form規定のactionでは飛ばなくなるので自前でGatsbyのnavigateを使ってPost処理が終わったらThanksページに飛ぶようにします。

```typescript{numberLines: 1}{11-12}
  handleSubmit(e) {
    e.preventDefault();
    const form = e.target;
    fetch('https://getform.io/f/897f187e-876d-42a7-b300-7c235af72e6d', {
      method: 'POST',
      body: Contact.encode({
        'form-name': form.getAttribute('name'),
        ...this.state,
      }),
    })
      .then(() => navigateTo(form.getAttribute('action')))
      .catch((error) => alert(error));
  }

これでGetForm無料版でも自前のThanksページを作ることができます。

GitHub Actionsでビルドとデプロイ

ここまで来たらあとはGitHub Actionsでビルドとデプロイを行うだけです。

masterブランチへのPRでPreviewデプロイ、masterへのコミットで本番デプロイをするように2つactionsを作ります。

まずはPreviewデプロイ

name: DeployToNetlifyPreview
on:
  pull_request:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v2
      - name: Cache node_modules
        uses: actions/cache@v1
        with:
          path: node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.OS }}-build-
            ${{ runner.OS }}
      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: npm install and build
        env:
          GATSBY_GITHUB_CLIENT_SECRET: ${{secrets.GATSBY_GITHUB_CLIENT_SECRET}}
          GATSBY_GITHUB_CLIENT_ID: ${{secrets.GATSBY_GITHUB_CLIENT_ID}}
          GATSBY_ALGOLIA_SEARCH_API_KEY: ${{secrets.GATSBY_ALGOLIA_SEARCH_API_KEY}}
          GATSBY_ALGOLIA_INDEX_NAME: ${{secrets.GATSBY_ALGOLIA_INDEX_NAME}}
          GATSBY_ALGOLIA_APP_ID: ${{secrets.GATSBY_ALGOLIA_APP_ID}}
          GATSBY_ALGOLIA_ADMIN_API_KEY: ${{secrets.GATSBY_ALGOLIA_ADMIN_API_KEY}}
          FAUNADB_SERVER_SECRET: ${{secrets.FAUNADB_SERVER_SECRET}}
        run: |
          npm install
          npm run build
      - name: Deploy to netlify
        run: npx netlify-cli deploy --dir=./public > cli.txt
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
      - name: Cat cli.txt
        run: |
          cat cli.txt
          sed -i -z 's/\n/\\n/g' cli.txt
      - name: Post Netlify CLI Comment
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          URL: ${{ github.event.pull_request.comments_url }}
        run: |
          curl -X POST \
               -H "Authorization: token ${GITHUB_TOKEN}" \
               -d "{\"body\": \"$(cat cli.txt)\"}" \
               ${URL}

node setupやnpm install, buildはいつも通りです。

GitHub ActionsではSecretを指定することができますので、Algolia searchやFaunaDBのAPIキーはシークレットとしてビルド時の環境変数で渡してます。

ちなみに、環境変数でGATSBY_XXXXとしておくと、ビルドされたJSにも環境変数が入る形になります。（JSから環境変数を使う場合はこれを忘れないこと。）これ結構詰まるポイント。

デプロイにはnetlify-cliを使います。

必要な環境変数はサイトIDとAUTH TOKENです。

ちょっと特徴として、netlify-cliでデプロイが成功すると、デプロイURLが標準出力に出ますので、それをいったん適当なtextファイルに書き出し、

PRコメントにもURLを送るようにしています。

GitHub Actionsの素晴らしいところは、GITHUB TOKENについては、特に設定しなくてもsecrets.GITHUB_TOKENで取り出すことができますので簡単にPRコメントに送信できます。

      - name: Deploy to netlify
        run: npx netlify-cli deploy --dir=./public > cli.txt
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
      - name: Cat cli.txt
        run: |
          cat cli.txt
          sed -i -z 's/\n/\\n/g' cli.txt
      - name: Post Netlify CLI Comment
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          URL: ${{ github.event.pull_request.comments_url }}
        run: |
          curl -X POST \
               -H "Authorization: token ${GITHUB_TOKEN}" \
               -d "{\"body\": \"$(cat cli.txt)\"}" \
               ${URL}

次に本番へのデプロイです。

name: DeployToNetlifyPRD
on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v2
      - name: Cache node_modules
        uses: actions/cache@v1
        with:
          path: node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.OS }}-build-
            ${{ runner.OS }}
      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: npm install and build
        env:
          GATSBY_GITHUB_CLIENT_SECRET: ${{secrets.GATSBY_GITHUB_CLIENT_SECRET}}
          GATSBY_GITHUB_CLIENT_ID: ${{secrets.GATSBY_GITHUB_CLIENT_ID}}
          GATSBY_ALGOLIA_SEARCH_API_KEY: ${{secrets.GATSBY_ALGOLIA_SEARCH_API_KEY}}
          GATSBY_ALGOLIA_INDEX_NAME: ${{secrets.GATSBY_ALGOLIA_INDEX_NAME}}
          GATSBY_ALGOLIA_APP_ID: ${{secrets.GATSBY_ALGOLIA_APP_ID}}
          GATSBY_ALGOLIA_ADMIN_API_KEY: ${{secrets.GATSBY_ALGOLIA_ADMIN_API_KEY}}
          FAUNADB_SERVER_SECRET: ${{secrets.FAUNADB_SERVER_SECRET}}
        run: |
          npm install
          npm run build
      - name: Deploy to netlify
        run: npx netlify-cli deploy --prod --dir=./public
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

ほとんど同じですが、netlify-cliでdeployコマンドに --prodオプションを入れることで、本番環境へデプロイされます。

      - name: Deploy to netlify
        run: npx netlify-cli deploy --prod --dir=./public
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

結論

これで、Netlifyのビルド時間は0になり、精神的に安心できるようになりました。

リファクタや記事の執筆もはかどっていいですね！！

Github Actions のバッジを付ける (＋バッジに Github Actions ページへのリンクを付与するChrome拡張機能を作成)

2021-01-06T23:45:20+09:00

前回記事の続き。 Github Actions で PHPUnit が走ることが確認できたところで、今度は「そういえば Github Actions のバッジはあるのだろうか？」と気になって調べてみました。

バッジの所在

バッジについては Github Actions のページにありました。

リポジトリの対象アクション ( https://github.com///actions? ) に遷移
上のハンバーガー( … ) からメニューを開く
Create status badge をクリック

以上の手順で発行できます。

メニュー展開時。

ダイアログ表示。

バッジを readme.md に貼り付けてみました。

バッジのリンクを変更する Chrome拡張機能

ところで、

GitHub Actionsのバッジをリンク付きでREADMEに追加する - Qiita

こちらの記事で「デフォルトのバッジ画像の Markdownコードは画像のみとなっていて対象の Github Actions へのリンクにはなっていないのが不便」とありました。確かに……。

上記の記事では UserScript で該当の Markdownコードを書き換える方法を紹介していましたが、個人的には Chrome拡張機能で充分な気がしたのでざっくり自前で作ってみました。

リポジトリ

arm-band/chrome_extensions_cambadge

manifest.json

{
    "manifest_version": 2,
    "name": "cambadge",
    "description": "Github Actions のバッジのURLを変更する拡張機能です。",
    "version": "0.0.1",
    "browser_action": {
        "default_icon": {
            "19": "icon_19.png",
            "38": "icon_38.png"
        },
        "default_title": "cambadge"
    },
    "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",
    "content_scripts": [
        {
            "matches": [
                "https://github.com/*"
            ],
            "js": [
                "main.js"
            ]
        }
    ]
}

main.js

/**
 * cambadgeCampaign: rewrite markdown code in textarea
 *
 * @param {object} DOMBadgeMd
 */
const cambadgeCampaign = (DOMBadgeMd) => {
    if (/^\!\[(.*)\]\((.*)\)$/gi.test(DOMBadgeMd.textContent)) {
        DOMBadgeMd.textContent = `[${DOMBadgeMd.textContent}](${location.href})`;
    }
};

window.addEventListener('load', (e) => {
    // triggered load
    if (/https:\/\/github\.com\/(.*)actions(.*)/gi.test(location.href)) {
        // only github actions page
        const clickItem = document.querySelector('summary[data-test-selector="badge-builder-button"]');
        clickItem.addEventListener('click', (ev) => {
            // triggered click of element:summary[data-test-selector="badge-builder-button"]
            let setIntervalId;
            let DOMBadgeMd;
            function findTargetElement () {
                // watch until find element:#badge-markdown
                DOMBadgeMd = document.querySelector('#badge-markdown');
                if (DOMBadgeMd !== null && DOMBadgeMd !== undefined) {
                    // found
                    clearInterval(setIntervalId);

                    // call function
                    cambadgeCampaign(DOMBadgeMd);
                }
            };
            setIntervalId = setInterval(findTargetElement, 100);
        });
    }
});

ダイアログ中の #badge-markdown を含むバッジ生成の要素は Create status badge をクリックした際に生成されるようなので、 Create status badge をクリックした後、 #badge-markdown が見付かるまで書き換えの処理を待つようにしました。

Chrome拡張機能で書き換えられたダイアログ。これで該当の Github Actions ページへのリンクに繋がるようになりました。

参考

バッジ

バッジのリンクを変更する

GitHub Actionsのバッジをリンク付きでREADMEに追加する - Qiita

UserScript

UserScriptで業務改善

Github Actions で PHPUnit を走らせる

2021-01-05T22:38:21+09:00

Github Actions で ESLint や Stylelint 、あるいはデプロイのワークフローは走らせたことがありますが、 Jest も行けるはず……と思い至ったところで、ふとそういえば PHPUnit はどうでしょうか、と思い実験。

検証

検索すると、

これらの記事がヒットしました。そこで、この記事を参考に .github/workflows/test.yml として作成。

.github/workflows/test.yml

name: PHPUnit test

on: [push]

jobs:
  test:
    name: Test

    runs-on: ubuntu-latest

    strategy:
      matrix:
        php-version: ['7.4']

    steps:
    - name: Setup PHP ${{ matrix.php-version }}
      uses: shivammathur/setup-php@v2
      with:
        php-version: ${{ matrix.php-version }}
        extension-csv: mbstring, xdebug, dom

    - name: Add Plugin
      run: sudo apt install -y php7.4-xml

    - name: Checkout
      uses: actions/checkout@v2

    - name: Check PHP Version
      run: php -v

    - name: Check Composer Version
      run: composer -V

    - name: Check PHP Extensions
      run: php -m

    - name: Validate composer.json and composer.lock
      run: composer validate

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress --no-suggest

    - name: Run test suite
      run: composer run-script test

試しに Github に push してみます。

走りました。

先人の知恵があればこそですが、 workflows の yml ファイルがあれば PHPUnit のテストも可能ということが分かりました。

参考

Github Actions で PHPUnit

composer

Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

2020-12-10T00:55:08+09:00

はじめに

Zenn や Qiita, note など様々なウェブサービスで記事を書くにつれて、ふと雑多な内容で自分の好き勝手に記事を書いて公開できる自分のブログが欲しくなりました。そこで、自分のブログを作ろうと思い調査したところ、SSG で作るのが手っ取り早そうだったのと、その中でも一番ラクにウェブサイトが構築できそうな Hugo を採用しました。

また、デプロイは簡単に行いたかったので、デプロイ先として GitHub Pages を採用しました。
独自ドメインの割り当てから HTTPS 対応まで無料でできるかつ、使い慣れている GitHub をデプロイ先に使えることが決め手でした。

Hugo で自分のブログを構築して GitHub Pages で公開できるようになったのですが、ブログ内容を更新したり記事を書くたびにビルドしてデプロイをするのが、意外と面倒なことに気づきました。そこで、GitHub Pages action を用いて、ビルドしてデプロイするという作業は自動化しました。

上記までの作業をすることで、自分のブログを書いたり更新することだけに集中できる環境を整えることができました。ウェブサイトを作りこむ以外は、簡単ないくつかの作業をするだけで Hugo で満足のいく自分のブログを書く環境が整えられたので、その手順についてまとめてみました。

ちなみに本記事の手順で実際に作成した私のブログは下記です。
https://nikaera.com/

Hugo を PC にインストールする

私は Windows には Chocolatey、Mac では Homebrew で Hugo をインストールしました。Chocolatey や Homebrew を利用したインストール方法については公式サイトの手順で公開されています。

# Mac で Homebrew を使って Hugo をインストールする
brew install hugo

# Windows で Chocolatey を使って Hugo をインストールする
choco install hugo -confirm

# Sass/SCSS を用いてウェブサイトのデザイン改修を行いたい場合は
# 下記で Chocolatey を使って Hugo をインストールする
choco install hugo-extended -confirm

Hugo で自分のウェブサイトを構築する

Hugo プロジェクトを作成する

下記コマンドで Hugo のプロジェクトフォルダを生成できます。

hugo new site <プロジェクトフォルダのパス>

Hugo のコンフィグファイルのデフォルトフォーマットは TOML 形式なのですが、hugo new site <プロジェクトフォルダへのパス> -f json のように -f オプションを付与することで JSON フォーマットでもコンフィグファイルを生成可能です。

後述しますが、一部の Hugo のテーマはコンフィグファイルのサンプルが JSON ファイルで書かれています。その場合は、新規で設定するコンフィグファイルのフォーマットも JSON で統一しておくと各種設定項目の調整が楽になりそうです。

もしくはこちらのようなコンバーターを使用したり、こちらのようなウェブのコンバーターを使用して、設定ファイルを JSON から TOML フォーマットに変更しても良さそうです。

ウェブサイトのテーマを探す

テーマとは、ウェブサイトのデザインテンプレートのことです。テーマは Hugo Themes で公開されているので、この中から自分の好みを選びます。Hugo ではテーマの内容をカスタマイズしたり差し替えることもできるので、あとから一部デザインを自分好みに修正できます。

Hugo Themes にアクセスした時のページ

お気に入りのテーマが見つかったら、Download ボタンをクリックしてテーマの GitHub URL を控えておきます。

Kiera というテーマのページ

Hugo プロジェクトにテーマを適用する

テーマの適用方法については公式サイトの手順で紹介されていますが、Hugo のプロジェクトフォルダのルートで下記コマンドを実行して、コンフィグファイルに theme を追記するだけです。

git clone <テーマの GitHub URL> themes/<テーマ名> --depth=1
echo 'theme = "<テーマ名>"' >> config.toml

どのテーマも基本的に適用方法は同じで、例えば私が採用したテーマである PaperMod を適用する場合は下記コマンドを実行することになります。

git clone https://github.com/adityatelange/hugo-PaperMod themes/hugo-PaperMod --depth=1
echo 'theme = "hugo-PaperMod"' >> config.toml

これで自分のウェブサイトを作り込んでいくための準備が整いました。

ウェブサイトを作り込む

各テーマには exampleSite というウェブサイト作成の参考になる Hugo のプロジェクトフォルダが存在します。 最初は exampleSite フォルダ内に存在する各種ファイルを自分のプロジェクトにコピー&ペーストして、改変しながらウェブサイトを作り込んでいくとスムーズに作業が進められます。

exampleSite フォルダは大抵 GitHub プロジェクトのルートに存在しているのですが、GitHub のブランチで管理しているものもあります。 私の採用した PaperMod は GitHub の exampleSite ブランチで管理していました。

上記のような詳細は Hugo のテーマページに記載があるはずなので、事前に exampleSite フォルダが配置されている場所や設定可能な項目等をチェックしておくことをオススメします。実際のウェブサイトの見た目を確認するには、Hugo のプロジェクトフォルダのルートで下記コマンドを実行します。

hugo server

hugo server 実行中に、ウェブサイトの設定を変更したり記事を追加すると、自動的にビルドが実行されるので常に最新のウェブサイトの見た目を確認できます。また、その際にエラーもコンソールに出力されるので、適宜修正しながらウェブサイトの作成を進めていくことが可能です。

GitHub にデプロイ環境を整える

ウェブサイトの構築が出来ればあとはデプロイするだけです。今回は GitHub Actions でデプロイするため、残りの作業は GitHub 上で進めていきます。一応 GitHub Actions を使わずに手動でデプロイする手順については、Hugo の公式サイトの手順にて紹介されています。

GitHub Actions を用いてデプロイできるようにした際の利点としては下記があります。

デプロイ時に毎回手動で複数コマンド実行する手間が省ける
自動化することでデプロイ時のコマンドミスを防ぐことが可能
常に統一した Hugo のビルド環境が利用可能

最初のうちは私も公式サイトの手順通りに Mac で手動デプロイしていました。しかし、Windows 環境でデプロイ作業した際、本番環境デプロイ時に SRI 関連のエラーが発生してしまい、ウェブサイトに stylesheet が適用されないバグが発生してしまいました。

結局原因はよく分からなかったのですが、GitHub Actions 経由でデプロイするようにしたところ直りました。CI 経由でデプロイできるようになると、こういった実行環境の違いによる挙動も気にする必要が無くなります。

一応 Windows 環境で発生した SRI 関連のバグは Hugo で該当するテンプレートファイルを layouts フォルダを利用して差し替えて、integrity の設定内容を空にすることで、本番環境でも stylesheet が適用できるようになったことは確認しました。詳細はこちら。

自分のウェブサイトをデプロイするためのリポジトリを作成する

GitHub の公式サイトの手順に従って、自身のウェブサイトをデプロイするためのリポジトリを作成します。また本記事では、Hugo プロジェクトのリポジトリはデプロイ用リポジトリとは別で扱うため、Hugo プロジェクトのリポジトリも新たに作成します。

本記事では Hugo プロジェクトのリポジトリ名は hugo-blog という名前に設定した前提で進めていきます。また作成したリモートリポジトリの情報は、下記コマンドで Hugo プロジェクトに登録しておきます。

# Hugo プロジェクトフォルダのルートで Git リポジトリを作成する
git init

# Hugo プロジェクトのリポジトリ情報を登録しておく (hugo-blog の GitHub URL)
git remote add origin

GitHub Actions で Hugo のビルドからデプロイまでを自動化するための環境を整える

今回は hugo-blog という Hugo プロジェクトのリポジトリから、デプロイ用リポジトリへデプロイしたいため、まずはデプロイ用リポジトリでデプロイキーを登録します。公式サイトの手順に従いデプロイキーを登録したら、秘密鍵を hugo-blog リポジトリのシークレットに登録します。

シークレットは公式サイトの手順に従って登録します。今回は秘密鍵をシークレットに登録する際の名前に ACTIONS_DEPLOY_KEY を設定した前提で進めていきます。

次に GitHub Pages action を導入して Hugo のビルドから公開までを自動化する環境をセットアップします。

hugo-blog リポジトリに GitHub Pages action の Getting started を参考にワークフローファイルを追加します。- name: Deploy の項目のみデプロイ用リポジトリへデプロイするために設定内容を変更します。

# .github/workflows/gh-pages.yml
name: github pages

on:
  push:
    branches:
      - main  # Set a branch name to trigger deployment

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: '0.78.2'

      - name: Build
        run: hugo --minify

    #   - name: Deploy
    #     uses: peaceiris/actions-gh-pages@v3
    #     with:
    #       github_token: ${{ secrets.GITHUB_TOKEN }}
    #       publish_dir: ./public
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          external_repository: nikaera/nikaera.github.io
          publish_branch: main
          cname: nikaera.com

- name: Deploy の項目で設定した各種パラメータは下記になります。

キー	説明
deploy_key	デプロイ時に使用する秘密鍵
external_repository	デプロイ先のリモートリポジトリ
publish_branch	デプロイ先のリモートリポジトリのブランチ
cname	設定するカスタムドメイン名

deploy_key にはシークレットに登録した秘密鍵を設定します。external_repository には Hugo をビルドした際のデプロイ先リポジトリを <ユーザ名>/<リポジトリ名> のフォーマットで指定します。publish_branch はデプロイ先として使用するブランチ名になります。cname には自分が設定したいドメイン名を指定します。cname の詳細はこちらからご確認いただけます。

カスタムドメインで設定した内容で DNS 設定を書き換える

GitHub Pages にカスタムドメインを利用する際は、該当するドメインの DNS レコードの設定で CNAME レコードもしくは A レコードを設定する必要があります。公式サイトの手順に従って設定します。

また、カスタムドメインの設定後は特別な理由がない限りは、デプロイ用リポジトリで HTTPS 強制の設定をしておくことオススメします。

ちなみに GitHub Pages で利用している証明書は Let's Encrypt のものになります。

設定作業はこれで完了です。あとは実際に Hugo プロジェクトを更新後、hugo-blog リポジトリに push することでビルドからデプロイまで GitHub Actions で行われるようになったかを確認していきます。

Hugo プロジェクトの更新時に自動でデプロイが行われるか確認する

Hugo プロジェクトには既に hugo-blog リポジトリの GitHub URL が origin として設定されているはずなので、下記で実際に hugo-blog リポジトリへ push してみます。

# Hugo プロジェクトを hugo-blog リポジトリに push する
git add -A
git commit -m "initial commit"
git push origin main

次は実際に GitHub リポジトリの Actions タブから、GitHub Pages action のワークフローが実行されているか確認します。

GitHub Pages actions の実行に成功した様子

無事ワークフローの実行に成功したことを確認したら、デプロイ用リポジトリの様子を確認します。

デプロイ用リポジトリに Hugo の最新ビルドが push されていることを確認する

最新コミットのメッセージに deploy: <ユーザ名>/hugo-blog@<コミットハッシュ> のコメントが表示されているはずです。コメントのリンクをクリックすると、hugo-blog リポジトリの最新コミットの確認画面に遷移するはずです。

ここまで確認できれば、あとはローカルで hugo server して確認していたウェブサイトと同じように、GitHub Pages 上でもウェブサイトが見えるか実際に確認してみます。

デプロイ用リポジトリ名が <ユーザ名>/<ユーザ名>.github.io であった場合、https://<ユーザ名>.github.io でウェブサイトにアクセスできます。私の場合は https://nikaera.github.io になります。その際、カスタムドメインにリダイレクトすることも確認できれば、カスタムドメインの設定も正常に反映されています。

ページが正常に表示されていてカスタムドメインでアクセスできた様子

アクセス時に意図したページが表示されていることが確認できれば大丈夫です。これで自分のウェブサイトを更新したら hugo-blog リポジトリに Hugo プロジェクトを push するだけで自分のウェブサイトを自動更新できるようになりました。

おわりに

今回は Hugo を例にしましたが、本記事内で紹介した GitHub Pages action は様々な SSG に対応しています。そのため Hugo ではウェブサイトのカスタマイズに限界が来たなと感じたら Next.js や Gatsby に乗り換えるといったことも可能です。

また Hugo では何も考えずとも、マークダウンで記事が書けてビルドも高速なので、手っ取り早く自分のウェブサイトを構築してみたいという用途にはピッタリだと感じました。

関係ないですが、Hugo でウェブサイト構築する際の知見も記事に含めてしまったせいで、文章量が意図した倍近い量になってしまいました。。簡潔で分かりやすい文章が書けるようにならなきゃ。。

参考リンク

hugoをgithub-actions上でbuildした際、lastmodの更新がすべての記事に適用される問題を解決した

2020-04-04T10:47:33+09:00

はじめに

hugoのジェネレートをGitHub-actionsを使って、pushするだけでデプロイできるようにしたのですが、全記事の最終更新日が更新されていたため原因調査をおこないました。

TL;DR

gitのcloneを行う際に最新コミットしか取得していなかった
actions/checkoutを利用する場合は以下の方法でfetchを行わせ、全履歴を取得しておく

- uses: actions/checkout@v2
  with:
    fetch-depth: 0    # Fetch all history for .GitInfo and .

試したこと

GitHub-actions上とlocalの比較

icon	結果
✅	更新対象記事のみlastmodが更新されていた
❎	すべての記事に対して更新が入っていた

ローカル
- ✅MacOSでのビルド
- ✅Vagrant内のUbuntu:18.04.4でのビルド
CI環境
- ❎Ubuntu:ubuntu-18.04でのビルド
- ❎MacOS:latestでのビルド
- ✅hugoのビルドを省いてデプロイ
- ❎オプションを外してビルド
- ❎既存のworkflowを使わずにコマンドでインストール（下記コマンドを実行）
```
wget https://github.com/gohugoio/hugo/releases/download/v0.68.3/hugo_0.68.3_Linux-64bit.deb
sudo apt-get install -y ./hugo_0.68.3_Linux-64bit.deb
```

git周りの確認

参照先のcommitIDが対象コミットのcommitIDになっているか
- 対象のコミットIDでした
git logの結果が正常に表示されているか
- CI上のログでは、1件しか表示されていなかった

結果

actions/checkout@v2という公式のworkflowを利用してgitのcloneを行っていたのですが、デフォルトでは最新のコミットしか取ってこないようです。
更新日時の参照先が見つけられなくなるため、すべての記事が最新のコミット更新日時を取得しに行ってしまったのだと思います。

# Number of commits to fetch. 0 indicates all history.
# Default: 1
fetch-depth: ''
https://github.com/actions/checkout#usage

すべての履歴をcloneしてくることで、解決しました。
GitHub Actionsのymlファイルでは、以下のように記載するようです。

- uses: actions/checkout@v2
 with:
   fetch-depth: 0    # Fetch all history for .GitInfo and .
https://github.com/peaceiris/actions-hugo#️-create-your-workflow

さいごに

最初はhugoのセットアップに使っているworkflowが悪いのかを疑ってたせいで、結構解決までに時間がかかりました…

今回のような問題を早期発見するために、確認用のStepも入れたほうが良いのかなと思いました。

参考

GitHub ActionsでMySQLを使ったLaravelのテストを実行する

2020-02-20T18:48:36+09:00

GitHub ActionsでMySQLを使ったLaravelのテストを実行してみたら出来たのでメモ。

アクションを作成する時にLaravelの雛形が選べるようなので、とりあえずそちらを使って作成する。雛形を下記のように置き換えた。

name: Laravel

on: [push]

jobs:
  laravel-tests:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        ports:
          - 3306
        options: --health-cmd "mysqladmin ping -h localhost" --health-interval 20s --health-timeout 10s --health-retries 10
        env:
          MYSQL_ALLOW_EMPTY_PASSWORD: yes
          MYSQL_DATABASE: laravel

    steps:
      - uses: actions/checkout@v2
      - name: Copy .env
        run: php -r "file_exists('.env') || file_put_contents('.env', str_replace('DB_PORT=3306', 'DB_PORT=${{ job.services.mysql.ports['3306'] }}', file_get_contents('.env.example')));"
      - name: Cache vendor
        id: cache-vendor
        uses: actions/cache@v1
        with:
          path: vendor
          key: ${{ runner.os }}-vendor-${{ hashFiles('**/composer.lock') }}
      - name: Install Dependencies
        if: steps.cache-vendor.outputs.cache-hit != 'true'
        run: composer install -q --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist
      - name: Generate key
        run: php artisan key:generate
      - name: Directory Permissions
        run: chmod -R 777 storage bootstrap/cache
      - name: Execute tests (Unit and Feature tests) via PHPUnit
        run: vendor/bin/phpunit

やったこと

下記が追加で編集したもの。

MySQLの設定

もともとはSQLiteでテストが行われる設定になっていたが、ちゃんとMySQLで実行したいのでその設定。まずはservicesにMySQLのサービスを追加。optionsはよくわからないがコンテナが落ちてしまうらしいので追加している。そのうち不要になるのでは。

接続の設定は .env.example をコピーして使う。そのため、その設定に合わせてこのサービスのenvを設定する。具体的な設定はDockerHubのmysqlイメージのところに書いてある。

ポートは ${{ job.services.mysql.ports['3306'] }} という感じでサービスのポートを参照できる。ホストはローカル。ただしlocalhostでなく127.0.0.1としないとつながらないっぽい。