Move GitHub Actions secrets to environments

[marcoieni]

Secrets in this workflow don't run inside an environment: https://github.com/rust-lang/compiler-builtins/blob/main/.github/workflows/rustc-pull.yml

We created the rustc-pull GitHub environment. We can move the secrets there.

I'm trying to understand if the syntax of how this job is defined supports environments.

[marcoieni]

I investigated this more and opened an issue in zizmor: zizmorcore/zizmor#1773

TLDR: we can't have environment in reusable jobs.

Since this workflow is reused in many places, imo we should create a proper GitHub Action.

[tgross35]

Any idea how difficult it is to create an action from a reusable job?

Cc @Kobzol

[Kobzol]

Well, I certainly wanted to avoid it 😆 Because maintaining a single YAML file is easier than turning it into a full action and writing it in JavaScript.

But this action is relatively simple, so if it's needed, probably not such a big deal.

TLDR: we can't have environment in reusable jobs.

GitHub Actions strike again.. this sucks.

I wanted the reusable logic to also be a workflow, because it then shows the performed steps more clearly, rather than if it was just a single black-box step. But if it is important because of security to use environments everywhere, then I guess we would have to turn it into an action 🤷‍♂️

That being said, I'm not 100% sure if secrets: inherit is really required. I'll do some experiments.

[Kobzol]

I did some tests in Kobzol#7, and I think that it actually works. We just have to add an environment input to the reusable workflow, and specify the environment which should be used for the jobs of the reusable workflow. And then define the secrets in that same environment in the calling workflow. The secret was then propagated in my test, even across repositories.

[Kobzol]

Let's try it with rust-lang/josh-sync#39.

[marcoieni]

Well, I certainly wanted to avoid it 😆 Because maintaining a single YAML file is easier than turning it into a full action and writing it in JavaScript.

No need for the action to be in JavaScript. You can have composite actions https://docs.github.com/en/actions/tutorials/create-actions/create-a-composite-action

[marcoieni]

Let's try it with rust-lang/josh-sync#39.

one inconvenience of this approach is that zizmor can't recognize it, since it's a custom solution.
So we would need to allow list every occurrence of this. I'm not sure it's possible today.

[Kobzol]

Well, I certainly wanted to avoid it 😆 Because maintaining a single YAML file is easier than turning it into a full action and writing it in JavaScript.

No need for the action to be in JavaScript. You can have composite actions https://docs.github.com/en/actions/tutorials/create-actions/create-a-composite-action

We do use two jobs in the shared workflow though, I remember that it would be fairly annoying with just steps and a single job.

one inconvenience of this approach is that zizmor can't recognize it, since it's a custom solution.

Yeah the problem with GHA secrets is that things like ${{ secrets.FOO $}} are evaluated lazily and dynamically, so that they can use the context of the place where it is evaluated. So I think that it is fundamentally impossible to precisely analyse if secrets come from an environment or not. In fact even if you had environment: foo and ${{ secrets.BAR }}, the secret might not be coming from the foo environment, because if the environment doesn't have that secret, the workflow would just use a repository secret with the name BAR, if it exists.