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

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

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

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

# badon: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です。

# goodon: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提供者としては選択肢を残してあげるほうが良さそうです。