我正在制作一些CICD，并且正在使用GitHub标签来展示用于部署生产的意图。
因此，在我的github动作中，我有一些布尔值，可以检查是否有“ deployprd”标签。有一张带有状态批准的拉动请求审查的支票。
但是...如果用户在批准后进行了一些代码，则批准在CICD的眼中仍然有效。
当用户添加标签“ deploy-prd'并运行CICD时，它只是看到现有批准并且有一个“ deploy-prd”标签，并部署了新承诺的未批准的代码。有没有办法将最新提交与批准的时间戳进行比较？还是我应该遵循另一种逻辑？
当前的解决方案仅使部署PRD仅通过管理员访问。
还：
在绩效，执行限制和未来的技术债务方面，同步触发以消除现有批准是一个好主意吗？还是这会导致下面的头痛更多？
是CICD工作流程的一些关键摘录。
拉请求触发标签
name: 'Label Trigger'
on:
pull_request:
types: [labeled]
jobs:
gcp-pull-request-ci:
if: github.event.review.state == 'approved'
uses: ${{github.repository}}/github-actions/.github/workflows/gcp-label-ci.yaml@master
with:
repository: ${{ github.repository }}
deploy-prod: ${{ contains( github.event.pull_request.labels.*.name, 'deploy-prd') }}
pull-request-number: ${{ github.event.pull_request.number }}
可重复使用的工作流程作业逻辑
check-for-deploy-prd:
needs: deploy-stg
if: inputs.deploy-prod
outputs:
data: ${{ steps.get_approved_prs.outputs.data }}
runs-on: ubuntu-latest
defaults:
run:
shell: bash
steps:
# Query approval status
- uses: octokit/[email protected]
id: get_approved_prs
with:
route: GET /repos/${{inputs.repository}}/pulls/${{inputs.pull-request-number}}/reviews
env:
GITHUB_TOKEN: ${{ secrets.token }}
deploy-prod:
needs: check-for-deploy-prd
if: contains(fromJSON(needs.check-for-deploy-prd.outputs.data).*.state,'APPROVED')
I'm making some CICD and I'm using github labels to demonstrate intent to deploy into production.
So in my github actions, I have some boolean that checks if there to be a label 'deploy-prd'. There's a check for pull request review with status approved.
But... if a user commits some code after it has been approved, then the approval is still valid in the eyes of the cicd.
When the user adds the label 'deploy-prd' and the cicd runs, it just sees that there is an existing approval and that there is a 'deploy-prd' tag and deploys the newly committed and unapproved code to prod. Is there a way to compare the latest commit to the timestamp of the approval? Or is there another logic I should follow?
The current soln is making deploy-prd only accessible by admins.. which is meh at best.
Also:
Would a synchronize trigger to remove existing approvals be a good idea in terms of performance, execution limits, and future technical debt? Or would this cause more headache down the line?
Below are some key excerpts from the cicd workflows.
Pull Request Trigger label flow
name: 'Label Trigger'
on:
pull_request:
types: [labeled]
jobs:
gcp-pull-request-ci:
if: github.event.review.state == 'approved'
uses: ${{github.repository}}/github-actions/.github/workflows/gcp-label-ci.yaml@master
with:
repository: ${{ github.repository }}
deploy-prod: ${{ contains( github.event.pull_request.labels.*.name, 'deploy-prd') }}
pull-request-number: ${{ github.event.pull_request.number }}
Reusable workflow job logic
check-for-deploy-prd:
needs: deploy-stg
if: inputs.deploy-prod
outputs:
data: ${{ steps.get_approved_prs.outputs.data }}
runs-on: ubuntu-latest
defaults:
run:
shell: bash
steps:
# Query approval status
- uses: octokit/[email protected]
id: get_approved_prs
with:
route: GET /repos/${{inputs.repository}}/pulls/${{inputs.pull-request-number}}/reviews
env:
GITHUB_TOKEN: ${{ secrets.token }}
deploy-prod:
needs: check-for-deploy-prd
if: contains(fromJSON(needs.check-for-deploy-prd.outputs.data).*.state,'APPROVED')
发布评论
评论（1）
您可以创建一个分支规则，当做出新的提交时会陈旧批准。
There is a branch rule you can create that will stale approvals when a new commit is made.
How to un-approve github review after new commits automatically