Closed davepacheco closed 2 years ago
Per-repository configuration is likely the easiest thing. I could add an allow_users
list to the repo-level config file, where you could specify that those two users should always be authorised.
I wonder: how do these specific users get their access rights otherwise? I don't think they're organisation members, or this would probably just be working.
As part of looking at this, I've added another log statement around authorisation (c46bcfb44510b7016b4e8462407f85a89e8fa714) and then I requested the re-run of failed checks on a dependabot job. I have confirmed that it is doing what I expect:
Jun 11 03:00:30.134 INFO loaded delivery 667454 event check_run action rerequested
Jun 11 03:00:30.141 INFO re-running check "*control" for suite 6886704546/01G57T5WDE03WZBVP1X7D4ZQPT
Jun 11 03:00:33.896 INFO check suite 01G57T5WDE03WZBVP1X7D4ZQPT by dependabot[bot] (pull) needs authorisation
In this case it would be pretty easy to list the user dependabot[bot]
for that repository as pre-authorised.
Dependabot is part of GitHub. I'm not sure you have to do anything to authorize it. (I've noticed it's able to merge its PRs at your request without appearing to have rights to do so.) Renovate looks like an "application" that we've authorized (like buildomat).
Thanks! This sounds great. My only question is whether using the login name ("dependabot[bot]") is right. I don't know how GitHub expects you to identify bot identities and I'm not clear on whether dependabot's name is in the same namespace as ordinary users. I noticed that if I try to search for pull requests authored by dependabot, the filter is "author:app/dependabot" (as opposed to "author:dependabot" or "author:dependabot[bot]"). I guess as long as GitHub doesn't allow anybody to create a login of "dependabot[bot]", then this approach is at least safe!
I should add: I'm not able to confirm from https://github.com/oxidecomputer/dropshot/settings or https://github.com/oxidecomputer/dropshot/security how either dependabot or Renovate has privileges there. So I'm not sure my answer above is right. But I think for Dependabot, you only need to enable it by checking in its config file; and for Renovate you have a few options and I see that we do have a Renovate app listed on https://github.com/oxidecomputer/dropshot/settings/installations (though we also have other apps listed there we're not using).
I was looking at the actual object we get back for a lookup and it does seem like they populate the login
field in a backwards compatible way, by appending [bot]
to the application slug name and using it as the "login" for stuff done by those applications. I don't believe you can create an account with square brackets in the name. There is also a Bot
account type instead of User
for at least some of them.
I have implemented some support for this in 6ba1a570d17bb838205099946c4f716e1420fc8b which I am rolling out into other repositories:
I have also added a basic description of repository level configuration to the README: https://github.com/oxidecomputer/buildomat#per-repository-configuration
Thanks for this. It seems to be working well!
It looks like after the recent config change, dependabot PRs (and I expect renovate PRs) require explicit authorization from an Oxide org member in order to run the buildomat tests. This is pretty tedious because dependabot PRs wind up getting rebased and otherwise updated a lot before landing. This is particularly important for omicron and dropshot, though there are other repos that use dependabot and renovate.
I'm not sure how best to fix this. I don't think these users are really that special -- this could apply to any external contributor. But in the interest of urgency I could see a simpler mechanism that's constrained to these users. We could hardcode these users in the buildomat source or maybe make this configurable on a per-repo basis?