[英]Github Branch Protection rules vs. workflow permissions
我想實施這樣的規則,即每個(人類)用戶都必須打開 PR 才能更改受保護分支上的某些內容,而發布新版本的工作流能夠增加同一受保護分支上的版本號。
分支保護已到位,還選中了“包括管理員”復選框。 所以沒有人可以不小心推到那個分支。
現在,當我想從工作流中推送某些內容時,我會收到與用戶收到的相同的錯誤消息
name: Build pipeline
"on":
push:
branches:
- 'master'
defaults:
run:
shell: bash
jobs:
release:
runs-on:
- self-hosted
- default-runner
needs: []
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
clean: true
- name: demo push
if: github.ref == 'refs/heads/dev'
run: |
git config --global user.email "runner@xxx.com"
git config --global user.name "Github Actions Runner"
# normally we would generate the release notes here etc, increase the version,... though lets keep the example simple
date >> test.txt
git add test.txt
git commit -m "test2" test.txt
git push
在設置作業時,作業的權限被打印出來:
GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write
Deployments: write
Discussions: write
Issues: write
Metadata: read
Packages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
然后該步驟失敗並顯示以下 output:
user.email=runner@xxx.com
user.name=Github Actions Runner
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.xxx.com/xx/xxx
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
gc.auto=0
http.https://github.xxx.com/.extraheader=AUTHORIZATION: basic ***
branch.dev.remote=origin
branch.dev.merge=refs/heads/dev
[dev 7ddff59] test2
1 file changed, 1 insertion(+)
create mode 100644 test.txt
remote: error: GH006: Protected branch update failed for refs/heads/dev.
remote: error: You're not authorized to push to this branch. Visit https://docs.github.com/enterprise/3.2/articles/about-protected-branches/ for more information.
To https://github.xxx.com/xx/xxx
! [remote rejected] dev -> dev (protected branch hook declined)
error: failed to push some refs to 'https://github.xxx.com/xx/xxx'
Error: Process completed with exit code 1.
所以問題是:我如何強制人類用戶打開一個 PR,讓它在合並之前進行審查和檢查,而工作流可以直接操作(受保護的)分支?
經過一些研究,我發現目前(2022 年 6 月)沒有直接的解決方案( 來源)。
有兩種解決方法。 一種是去掉工作流中的zranch保護,之后再恢復。 風險在於工作流在兩者之間中斷(例如,當工作流運行器崩潰時)並且分支保持不受保護。 另一個風險是,用戶可能會無意或故意推送到現在未受保護的分支。 (例如,觸發發布構建等到分支保護被刪除並推送到該分支)。
另一種解決方案是刪除人類用戶的管理員權限,以便他們需要 PR 來更改受保護的分支。 在發布構建期間,使用具有管理員權限的技術用戶的 PAT(不是${{ secrets.GITHUB_TOKEN }}
)。 在分支保護中,“強制管理員”選項被禁用。
雖然有一個功能請求涵蓋了這個主題。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.