github actionsの「permissions」とはなにか？
not75743これのことです
permissions:
actions: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
id-token: read|write|none
issues: read|write|none
discussions: read|write|none
packages: read|write|none
pages: read|write|none
pull-requests: read|write|none
repository-projects: read|write|none
security-events: read|write|none
statuses: read|write|none
リポジトリへのpushの際にエラーに引っかかったため、調べてみます
not75743
permissionsでなにができる？
GITHUB_TOKENに付与される権限を操作できるようです。
You can use permissions to modify the default permissions granted to the GITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access. For more information, see "Automatic token authentication."
You can use permissions either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the permissions key within a specific job, all actions and run commands within that job that use the GITHUB_TOKEN gain the access rights you specify. For more information, see jobs.<job_id>.permissions.
GITHUB_TOKENとは何者なのか調べてみます
not75743
GITHUB_TOKENとはなにか
GitHub API を呼び出すための一時的な認証情報のようです。
こいつを設定することでgithubの様々な機能にアクセスできるんですね。
The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the GitHub API in your workflow runs. Actions generates a new token for each job and expires the token when a job completes. The token has write permissions to a number of API endpoints except in the case of pull requests from forks which are always read. These new settings allow you to follow a principle of least privilege in your workflows.
not75743
GitHub APIにはどんなものがあるか
以下に一覧がありました。デフォルトで有効なものも記載があります。
not75743
github actionsでGITHUB_TOKENを使う仕組み
以下を参考にすれば良さそうです。
ワークフローの実行開始時にGITHUB_TOKENを自動生成し、GitHub Appにアクセス可能。
ジョブが失敗するタイミング、または最大24時間でその権限は失効する
not75743実験①
以下のワークフローで実験してみます。
name: "permissions test"
on:
workflow_dispatch:
jobs:
test:
permissions: {}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
permissions: {}ですべての権限を無効化できるそうなので使ってみます
not75743実験① 結果
エラーになりました。
ログを見ると、リポジトリが見つからないとのこと
/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +xxxxxxxxxxxxxxxxxxxxx:refs/remotes/origin/main
remote: Repository not found.
なにかの権限が足りないのでしょう
not75743実験① 修正
以下のようにワークフローを修正したらうまくcheckoutできました
jobs:
test:
permissions:
contents: read
こちらに記載があり、真似したらうまくいった次第です
contentsはデフォルトでread権限が付与されるため、普段特に意識せずcheckoutが成功していたようです。
保留
名前から大体の想像はつくが、なぜcontentsを設定するのか
ググったけど公式ドキュメントには書いてなさげ...
not75743実験② リポジトリへのpush
次は以下のワークフローを試します。
Readmeを作成し、pushします。
name: "permissions test"
on:
workflow_dispatch:
jobs:
test:
permissions:
contents: read
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: git setting and push
run: |
echo "test" > README.md
git config user.name ${{ secrets.GIT_USER }}
git config user.email ${{ secrets.GIT_EMAIL }}
git add .
git commit -m "update README.md"
git push origin main
実験② 結果
エラーになりました。
ログを見ると、リポジトリへの書き込み権限が無いと怒られています。
remote: Write access to repository not granted.
fatal: unable to access 'https://github.com/***/<repo-name>/': The requested URL returned error: 403
これはわかりやすそうですね
not75743実験② 修正
permissionsを以下のように変更します。
jobs:
test:
permissions:
contents: write
readをwriteに変えるだけですね！
これでうまくpushできます。
not75743
なぜcontentsを設定する？
以下を参考にすると
permissionsはGITHUB_APPの権限に準じるそうです。
さらに
を見るとcontentsを設定する必要のあるAPIがわかります。
今回はリポジトリへのファイル書き込みを行ったので、↓を使ったものと思われます。
ということは、
- 実行したいgithubのAPIを探す
- そのAPIがどの
permissionsに該当するか探す - 見つけた
permissionsをワークフローファイルに書く
をやれば適切な権限が見つけられそうです。
（めんどくさい...）
not75743まとめ
リポジトリへのpushへは↓のように設定すればOK
jobs:
test:
permissions:
contents: write
理解も深まりました...が適切な権限を探すのが難しいですね。
クローズ
not75743以下参考にさせていただきました。