trusted_teams/trusted_users + various fixes
#1
Conversation
This resource can inadvertently miss Pull Requests due to out-of-order commits across PRs. If PR#2 is opened after PR#1, but the head commit of PR#2 is older than the head commit of PR#1, the resource will not include PR#2 in the list of new versions provided to Concourse. Rather than attempt to find a different way of tracking which PRs are "new" given an input version, we can remove the date-based filtering and return all open PRs. Concourse can deduplicate versions based on metadata, which means that we will only trigger new jobs for versions that Concourse hasn't seen before. This makes it easier for teams to use this resource to track PRs in Concourse, since they no longer have to ensure that a PR has a later head commit than all currently-opened PRs in order to notify Concourse that their PR exists.
This triggers CI when the approved review count changes, which is not the correct behaviour Co-authored-by: Kieron Browne <kbrowne@vmware.com>
This allows finer control of the RequiredReviewApprovals property. It is ignored if the user is in one of the trusted teams, or in the trusted user list. This way we can run CI on trusted users without needing an approval, but untrusted users will require a PR approval before their changes are run in CI. In order to reduce the number of calls to github we are caching trusted users for the duration of a single check. Note: github should be configured to remove approvals if new commits are received on a PR so that a user doesn't circumvent security by pushing a malicious commit after an approved legitimate commit on the same PR. Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com> Co-authored-by: Danail Branekov <danailster@gmail.com>
|
|
|
As a side note, I Think the version of this resource that's on dockerhub doesn't actually align with the version in code here D: I think there might be a commit on there that seems to be lost to history that's supposed to order the prs in order of approval date rather then commit date, but I can't find it. If I push over that, we might have to remake that part of the commit. |
|
After experimenting with the changes provided by PR, here is our feedback:
|
|
@b1tamara TY for giving this a closer look!! |
|
@b1tamara just to be clear, did you just use :latest, or push a fork? Cause if you wanted to test I'd push to a docker fork and use that to test. |
|
@Benjamintf1 |
Add details on `trusted_teams` and `trusted_users` source configuration parameters. Co-authored-by: Danail Branekov <danailster@gmail.com>
|
Hi all, Thanks for all the inputs and apologies for the delay addressing them.
We have never hit rate limits but that does not mean that it can never happen. How about trying it like it is and if it causes trouble we can introduce an opt-in feature flag.
That docker image is in the loggregator dockerhub repository which we do not have access to. Also, updating the released image is up to the repository owners.
We have documented the additional token permissions in the README
Done |
|
Howdy, sorry I didn't notice this earlier. Ran the pr tests and it's looking like we have a failure. if you could fix that we can talk more about possibly merging this. |
Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com>
|
Hey @Benjamintf1 The linter failed because there was an unused function. The function has been deleted. |
|
Image should be auto-created soon. |
This adds a few fixes and features needed by the Korifi team:
trusted_teamsandtrusted_usersconfiguration params, allowing to specify teams and users that are always authorised to run tests.