Use private runners & GitHub app token for Release jobs

[mars]

I'm trying to use this workflow with a private repo, and hit some snags.

[colincasey]

I'm hesitant about this change. The compile job only requires an allowlisted runner for the front-end buildpacks because the repository is private. Public repos don't need this and benefit from higher availability and docker rate limiting benefits using public runners. So switching to always use ip_allowlisted_runner would have a negative impact overall as all our buildpack repositories should (eventually) be public.

Contrast this with the jobs that absolutely require an allowlisted runner because they perform write actions against the repositories (e.g.; publish-github, update-builder). These jobs have no choice but to use the allowlisted runners.

To minimize impact on the more common case @mars, I think we should instead use one of the following alternatives:

• introduce an optional public input (defaults to true) and apply a conditional to the runs-on that chooses between the public runner and ip_allowlisted_runner
• run a step that calls the github api to determine if the repository is public or private and then chooses between the public runner and ip_allowlisted_runner
• introduce a default_runner input (defaults to ubuntu-24.04) so private repos can pass in an alternative

[edmorley]

Yeah I'd prefer to use the public runners (at least longer term), given publishing from a private repo is not a use-case we should be supporting longer term.

I'm also a bit hesitant to publish those CNBs from a private repo at all, even temporarily. We've committed to our buildpacks being open source - and whilst I'm sure the plan is to open source the repo soon, I think it might be better for optics if that happens first before the CNBs are published and added to the builder?

Otherwise it comes across to the community as "here's something we worked on in private, surprise!". Plus the repo URL will appear in a bunch of places (for example, the https://registry.buildpacks.io listing or the output of pack builder inspect heroku/builder:24), and the links will 404 until the repo is public, which will come across as a bit exclusionary.

The repo open sourcing process has also gotten a lot faster recently (Rune said the .NET repo was made public the day after the request was submitted), so waiting until the repo is public shouldn't block things too much?

[mars]

Thanks @colincasey for offering alternatives that could get this working.

@edmorley We're not ready to open-source the project I'm working on… I was under the impression that as long as the GitHub & Docker repos are private, that we would not be leaking preliminary releases to the public.

[edmorley]

Ah I didn't realise they weren't ready.

The release automation here presumes things are public, since it also registers the CNB releases on https://registry.buildpacks.io/ , which (a) means a public listing, (b) I think would fail, since the upstream CNB registry has to pull the image to fetch metadata to populate the listing etc - which it couldn't do from a private Docker repo/registry.

[colincasey]

We only need to fetch the token if we're doing some type of writable action against the repo, right? I don't think we need this for the checkout step. It should work for private repos as long as it's using an allowlisted runner.

[mars]

If checkout for read-only works without the GH app token, then I agree this is unnecessary.

[colincasey]

Is there a reason for moving this step? If not, maybe leave it where it was since it just seems like noise for this PR.

[mars]

I moved the step to before checkout, like the other jobs, but it sounds like that is unnecessary.

[mars]

Using an internal preview strategy to avoid these conundrums, until we're ready for public launch.