Open matklad opened 4 years ago
I saw the same error with {"status", "403 Forbidden"}
when trying to merge https://github.com/rust-osdev/bootloader/pull/85.
Happened again in another repo: https://github.com/ferrous-systems/flamegraph/pull/33
Same in https://github.com/rubygems/rubygems/pull/3064. Might be a duplicate of https://github.com/bors-ng/bors-ng/issues/783?
Looks like this definitely happens if PR in questions modifes github acitons themselves, but I think it also happens in some other cases (maybe when merge commit contains changes to actions along at least one ancestoral path?)?
Just posting here to confirm that we seem to get this problem consistently when an PR from an external fork modifies github actions files themselves. We run into this again in https://github.com/rubygems/rubygems/pull/3167, which meets both conditions.
I think we're seeing a variant of this in https://github.com/bryangingechen/mathlib/pull/21; in this instance, the external fork PR doesn't modify the github actions files, but there's a commit in master that did, so a merge commit into staging
or staging.tmp
fails.
Since this "Resource not accessible by integration" problem seems to be relatively common, could I request that bors handle it without crashing? (I'd be happy to contribute, but I don't know enough (any) elixir. If someone could give some pointers I'd be willing to have a go at it myself.)
Github announced a new workflow permission. This might fix this problem. @notriddle
We got also hit by this in the https://github.com/ddnet/ddnet respository (I guess admins of the public bors instance could check out the logs there).
It seems to happen whenever we modify a GitHub actions script. It would be nice if bors didn't fail the whole batch in this case, but try binary searching the diff that work and reporting that they didn't on the other pull requests.
@matklad Could you rename this issue to "Can't merge pull requests that modify Github actions"?
Since this "Resource not accessible by integration" problem seems to be relatively common, could I request that bors handle it without crashing?
I agree. Bors should comment on the PR saying something like "Insufficient permissions: I need the workflow permission".
Has anyone worked out how to add the permission to bors which is installed on a GH organisation (not a user)?
@vext01 From what I understand, the "workflow" permission (or any permission for that matter) can only be changed by the maintainer of the GithubApp. As users we've won't be able to change this setting. What is unclear to me is, once the permission has been changed by the maintainer, whether we need to approve that change, reinstall the app, or the change gets applied automatically.
https://developer.github.com/apps/managing-github-apps/editing-a-github-app-s-permissions/
Note: Updated permissions won't take effect on an installation until the owner of the account or organization approves the changes. You can use the InstallationEvent webhook to find out when people accept new permissions for your app. One exception is user-level permissions, which don't require the account owner to approve permission changes.
The problem seems to persist, even after adding the new Github actions permissions: https://github.com/ddnet/ddnet/pull/2185.
According to this forum post, github apps aren't allowed to merge PRs that touch github actions.
Wow, so GitHub basically makes it impossible to use an app like bors consistently for all PRs (which is exactly what bors is for)? I better don't migrate my bors-using repos to GHA then.
I better don't migrate my bors-using repos to GHA then.
TBH, for me personally bors + GHA feel like less maintenance than bors + {traivs,appveyor,azure} despite this issue. Though, I only migrate projects I actively develop. It certainly make the migration process itself more painful, as that is exactly when you edit actions :D
Is this still a problem? After I accepted the change in permissions for the hosted bors instance, I can now r+ pull requests. For example: https://github.com/jonasbb/rust_misc_utils/pull/45
It is (was?) only a problem for PRs from a fork. If you make a PR from the same repository, then it works fine.
So I am getting
error on some pull-request on rust-analyzer, but not on others. https://github.com/rust-analyzer/rust-analyzer/pull/2297 and https://github.com/rust-analyzer/rust-analyzer/pull/2316 (resubmission of the same commit as a new PR) failed with this error, but https://github.com/rust-analyzer/rust-analyzer/pull/2317 begun testing successfully.