GitHub Actions 最近のやらかし一覧（2022年夏）

2020年のやらかし一覧 に続いて、最近のやらかしも残しておきます。

PRがマージされたときだけPR番号を取得しそこねる

PR番号を取得するのに GITHUB_REF を使いがちですが、マージされたときだけはマージ先ブランチ名が入ってきてしまうので完全ではありません。

# bad
on:
  pull_request:
    types: [ opened, synchronize, reopened, closed ] # closedイベントも拾いたい
  jobs:
    bad-case:
      runs-on: ubuntu-latest
      steps:
        - run: |
            PR_NUMBER=$(echo $GITHUB_REF | sed -e 's/[^0-9]//g')
            echo "PR番号は${PR_NUMBER}です" # merge時には空文字が入ってしまう

pull_request イベントにちゃんと number が入っているので、これを使用すればOKです。

# good
on:
  pull_request:
    types: [ opened, synchronize, reopened, closed ]
  jobs:
    good-case:
      runs-on: ubuntu-latest
      steps:
        - run: |
            echo "PR番号は${PR_NUMBER}です"
          env:
            PR_NUMBER: ${{ github.event.pull_request.number }}

自分が配布するActionでsemantic tagsを提供しないほうが良いと思っていた

GitHub公式のセキュリティガイドに、クリエイターが信用できるときだけタグに依存して良い＝通常はフル長コミットSHAを使って依存せよ、と書いてあります。ので自分を信用するやつなんておらんやろの精神で v1 や v1.2 のようなsemantic-tagは提供してきませんでした。

ところが同じ公式ドキュメントで、semantic tagsを提供してねと推奨しているんですね。

Add a workflow that triggers when a release is published or edited. Configure the workflow to ensure semantic tags are in place. You can use an action like JasonEtco/build-and-tag-action to compile and bundle the JavaScript and metadata file and force push semantic major, minor, and patch tags. For an example, see this workflow. For more information about semantic tags, see "About semantic versioning."

有名企業でもやらかす世界線で個人開発者を信用するのはやめたほうが良いとは今でも思っていますが、信用するしないはユーザが決めるものなので、Action提供者としては選択肢を残してあげるほうが良さそうです。