Ensure additional commits after approval are rejected #11223
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When running this workflow manually (signalled via the `workflow_dispatch` event), we need to ensure that we are operating on commits that have been reviewed/approved. This is a safety measure to prevent: 1. Accidental pushes that might cause bugs. 2. Malicious pushes that might do nefarious things. I considered implementing this by re-checking for approval at the time we checkout the code, but because the `gh` call to check for approval is a separate call from the checkout, we will always need to do this SHA comparison to avoid a race. So the simplest thing was to memoize the SHA as part of the output from the first job and avoid another `gh` call. Lastly, this validation relies on `Dismiss stale pull request approvals when new commits are pushed` being set in the repo settings. It's already configured that way here in `dependabot-core`.
pavera
approved these changes
Jan 3, 2025
fd35568 to
798d3a1
Compare
Nishnha
approved these changes
Jan 3, 2025
landongrindheim
approved these changes
Jan 3, 2025
Comment on lines
+101
to
+104
| # Ensure the commit we've checked out matches our expected SHA from when we checked the PR's approval status above. | ||
| # This is a security measure to prevent any unreviewed commits from getting pulled into this action workflow. | ||
| # The format is "APPROVED:OPEN:<PR_COMMIT_SHA>", so compare the end of the string to the current commit. | ||
| [[ ${{needs.approval.outputs.decision}} =~ $(git rev-parse HEAD)$ ]] |
There was a problem hiding this comment.
💅 This is my preference, not a requirement.
I'd prefer we use two outputs instead of matching against a long string multiple times. I find exact matches quite a bit easier to reason about.
There was a problem hiding this comment.
I hear you... I actually wrote it that way originally--I also prefer explicit over implicit, but it got kinda verbose, so I decided it was more readable/simpler this route.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When running this workflow manually (signalled via the
workflow_dispatchevent), we need to ensure that we are operating on commits that have been reviewed/approved. This is a safety measure to prevent:I considered implementing this by re-checking for approval at the time we checkout the code, but because the
ghcall to check for approval is a separate call from the checkout, we will always need to do this SHA comparison to avoid a race. So the simplest thing was to memoize the SHA as part of the output from the first job and avoid anotherghcall.Lastly, this validation relies on
Dismiss stale pull request approvals when new commits are pushedbeing set in the repo settings. It's already configured that way here independabot-core.