https://cloudposse.com logo
Join Slack
Powered by
How do you prevent PRs, created by author A, from ...
# github-actions
r
How do you prevent PRs, created by author A, from getting commits from author B and then author B approving it to merge the PR ?
Or is that done using 
mergify
?
The PR i saw it on originally https://github.com/cloudposse-terraform-components/aws-s3-bucket/pull/6. I had approved it and to merge it, I had to merge changes from main which then prevented me from merging because my name was associated to the commits, meaning that i could not approve a pr with my own commits. Which is great. Now I want to replicate it in a different organization.
I did see this action alternatively. https://github.com/marketplace/actions/dismiss-code-reviews-from-collaborators Ideally, i want to see this in a github app or a github native setting so i can proliferate it to every repo in an org without needing to copy and paste an action in each repo.
e
There is a repository rule set and or a branch protection that can be applied that requires somebody who has not committed code to approve the PR
👍 1
1. Dismiss stale pull request approvals when new commits are pushed
2. Require approval of the most recent reviewable push
We use the first one at cloud posse
Supports 
extends
keyword and configuration can be inherited from a centralized location
Note the change is made to the centralized location. Do not automatically proliferate. You need to trigger a file change to the file for to apply. This was a deliberate designed decision in that app. The other app is essentially managed, but I like that the config in the previous example are alongside the repo themselves or the overrides are.
Separately, we have a customer who might be sponsoring the development of some terraform components that’ll work well with Atmos to manage your repository settings, including these.
Unfortunately, it doesn’t appear there’s a way to restrict it so that anyone who contributed to the PR cannot approve it.
r
Thanks Eric Hmm i swear i saw it. Maybe i can replicate it again to prove that I'm not crazy, or at least i hope I'm not crazy Yes safe settings app is great but only if this setting is available, if not, then a custom gh bot is needed...
2. Require approval of the most recent reviewable push
Ah, you’re right, it was definitely the 2nd one.
Whether the most recent reviewable push must be approved by someone other than the person who pushed it.
s
r
Nice action. It's too challenging for me to role that out across the org cause each repo would need that action. It's much easier with a GitHub bot
We use the first one [repository-settings] at cloud posse
Supports 
extends
keyword and configuration can be inherited from a centralized location
Oh this is news to me! I didn't know that it supported centralization and overrides. I thought only safe-settings did. Very cool. https://github.com/probot/octokit-plugin-config?tab=readme-ov-file#the-_extends-key The key is 
_extends
fyi for any readers. I wonder why GitHub maintains both projects if they are so similar in features.
e
No, only 
safe-settings
is by GitHub
👍 1
it's a fork of 
repository-settings
, but significantly different since it operates in a centralized model.
🤔 1
Here you can see how we use it
r
Thank you for sharing! I'll take a look. Who manages the repository-settings app then ?
Oh you're right. I looked at the repository-settings org and its one engineer from Github and another from John Deer
e
Yea, sounds about right.
👍 1
IMO, the best solution would be an atmos managed set of components, with drift detection, that can read configs from repos for overrides (e.g. 
!include
in atmos), and work with our GHA
🤔 1
r
If atmos managed it then that would mean addressing a lot of drift anytime something changed. The nice thing about the bot is not having to worry about that because every push to default branch auto syncs the changes... Unless you can also auto sync or auto apply changes with atmos so drift never occurs
Open in Slack
PreviousNext
Powered by