Repository navigation
Support cross-org remote policy references - #1359
Conversation
|
Thanks for your interest in palantir/policy-bot, @clarkemn! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request. |
Generate changelog in
|
clarkemn
changed the title
|
Policy bot definitely works with cross org policies today, as we use this functionality extensively internally on GHES (currently 3.19.x). Is policy-bot installed on both organizations, so it can read the policy? |
|
Hi @asvoboda We are not on GHES (we are on Github.com) and have a single GitHub App registered at the enterprise level, installed separately on each organization (so it has its own installation per org, not one shared cross-org installation). We hit an error when testing this cross-org access where a PR in one of our orgs referenced remote: The file does exist — the message is misleading. Tracing So back to your questions - yes, policy-bot is installed on both organizations — but each installation only has access to its own org's repos. The existing code never looks up the target org's installation for a cross-org remote: reference, it just reuses whatever client the caller already has. |
|
Thanks for clarifying. As you found (and as noted in #111), it's expected that Policy Bot cannot load remote policies from private (or internal) repositories right now. To add this support, I think the correct fix is actually in https://github.com/palantir/go-githubapp, another library that we maintain. As noted in your PR body, something like the At a high level, when this option is present, I think you want to modify the Once we release the change as part of |
|
@bluekeyes Thanks for taking a look! palantir/go-githubapp#618 is now open. If we're able to get that merged and released, I'll update this PR to take advantage of the new option |
|
Version 0.47.2 of |
Adds handler.CrossOrgConfigLoader which resolves remote: references to repositories in different GitHub organizations by looking up the target org's app installation, enabling policy-bot to fetch shared policies across organizational boundaries.
Replace appconfig.NewLoader with handler.NewCrossOrgConfigLoader in NewServer, passing cc, appClient via githubapp.NewInstallationsService, and shared repository config options.
The remote-fetch loader inherited appconfig's default .github org-fallback
behavior, so a missing or misconfigured remote policy file would silently
resolve to the target org's .github default policy instead of producing
the documented "invalid remote reference: file does not exist" error, with
that content mislabeled as coming from the requested remote. Add
appconfig.WithOwnerDefault("", nil) to disable the fallback, and add a
regression test that drives the real production loader end-to-end.
b7c597e to
8ec460a
Compare
asvoboda
left a comment
asvoboda
left a comment
There was a problem hiding this comment.
This looks pretty reasonable. Sorry about the delay in reviewing. Do you mind pushing a new commit to fix the oauth problem and I can allow CI for your branch?
✅ Successfully generated changelog entry!Need to regenerate?Simply interact with the changelog bot comment again to regenerate these entries. 📋Changelog Preview💡 Improvements
|
Before this PR
A
.policy.ymlcan reference a remote policy file viaremote: org/repo, but this only works if the remote repo is in the same GitHub org as the requesting repo. The fetch reuses the requesting repo's own app installation client, which has no access outside its org, so a cross-org reference fails (typically a 404) even when policy-bot is installed on the target org too.This blocks a common setup: one centrally managed policy repo referenced via
remote:from many other orgs in the same GitHub Enterprise. (The vendoredgo-githubapp/appconfigpackage has a commented-outWithPrivateRemotesstub referencing #111 describing this exact gap.)After this PR
A
remote:reference can now point to a repository in a different GitHub org than the one defining it, as long as policy-bot is also installed on that org — resolved by looking up the target org's own app installation(the same lookup
CrossOrgMembershipContextalready uses for cross-org team/org membership checks). Same-org remotes are unaffected: no installation lookup happens, the original client is reused exactly as before. Only 1 level of remote configuration is still supported, and a missing/misconfigured remote file still produces the same "invalid remote reference: file does not exist" error as before.Possible downsides?
None expected for existing setups — same-org remote references and local policy files go through unchanged code paths. For a genuinely cross-org
remote:reference, the resolution now depends on policy-bot's app being installed on the target org: if it isn't, the failure mode changes from a generic 404 to a clearer wrapped error ("policy-bot is not installed on organization ..."), which is a behavior change for anyone currently relying on that specific 404 message/error type, though none is known.