CI: refer to repo secrets in an early secret step

[gulducat]

The goal here is to minimize merge conflicts between OSS->ENT due to our using Vault only in private repos.

Let me know if this seems misguided, but my plan is to replace this new "Setup secrets" step in ENT with hashicorp/vault-action in such a way that the steps that use the secrets can reference them the same way ${{ steps.secrets.outputs.SECRET }} in both OSS and ENT.

Some changes to secrets themselves will still likely collide, but unrelated changes around lines that happen to contain secrets should not.

I've heard other projects just copy the workflows and maintain a separate ENT copy, but I personally find that to be unappetizing.

[tgross]

Any merge conflict in these files at all is 😿 because we have to manually fix it in 4 different branches. Rather than reducing it, why not eliminate the possibility entirely by using an include here? (Presumably GHA has some way of doing this even its just a YAML include, otherwise why did they give us the indignity of YAML? 😀 )

Then the OSS and ENT repos can have completely separate files and the OSS->ENT merge script can be changed to always use the file from the ENT repo (we do that for a couple other files).

[gulducat]

Presumably GHA has some way of doing this even its just a YAML include

That sounds nice, doesn't it? It's an old sore spot: actions/starter-workflows#245

GHA secrets seem to really resist being abstracted... Maybe I'm missing something, but all the solutions I've seen are some variety of hacky.

The nearest equivalent of a YAML include for this use case would probably be a "reusable workflow" (which can inherit all secrets, unlike a "composite action" which needs secrets passed in, defeating our current goal). But even with that, there's no GHA expression to do something like lookup(secrets, "MY_SECRET"). It's always static secrets.MY_SECRET, so an include-like reusable workflow would need to set up all secrets on each call. Maybe that isn't the worst thing?

Another differently-hacky option beyond what I started in this PR, is to also include the Vault lookup(s) here in OSS repo, but conditionally so it's only effective in ENT. That would put the Vault paths out in the open on a public repo, which is probably fine, but it would require all secrets for ENT (and many are ENT-only) be set up here in OSS.

I'm open to other suggestions, but after a decent bit of flailing around, what I started here still feels to me like a decent middle-ground, since secrets aren't added/removed all that often.

[tgross]

I'm open to other suggestions

We're stuck in the rut of trying to make GHA work the "GHA way". Run a shell script that's different in the two repos that sources the environment variables/secrets we need? We should have as much as possible in sensible shell scripts rather than magic yaml.

but after a decent bit of flailing around, what I started here still feels to me like a decent middle-ground, since secrets aren't added/removed all that often.

I'm worried we're going to get frequent merge conflicts despite your best efforts here. Merge conflicts and backport assistance failures are incredibly painful for us right now to the point where I've been seriously spending a lot of time advocating with leadership for shipping only 3 versions of Nomad instead of 6 just so to reduce the burden of dealing with the poor tooling we have.

Adding any new ways to have merge conflicts is a regression and we should not ship like that.

[gulducat]

closing in favor of the strategy set up in #17775