Update automated workflow to allow for overriding orgs for dockerhub and quay

[detiber]

Update automated workflow to allow for overriding orgs for dockerhub and quay

[detiber]

/assign @displague

[deitch]

@detiber a few questions:

• why do we have our own metadata action here? What does it do?
• why move the org names into secrets?

[detiber]

@detiber a few questions:

• why do we have our own metadata action here? What does it do?

It allows to standardize a bit how we are creating the metadata and avoiding some copy-pasta type issues, since it needs to be run by multiple jobs.

• why move the org names into secrets?

I'd rather not use a secret here TBH, but it's the only way that I could figure out how to override the value on a per-org basis, so that users can run/publish/test using their own quay/dockerhub/ghcr orgs for testing in their own forks.

Otherwise users would have to hack things up and override hardcoded values in the repo in order to override upstream quay/dockerhub orgs.

[deitch]

I'd rather not use a secret here TBH, but it's the only way that I could figure out how to override the value on a per-org basis, so that users can run/publish/test using their own quay/dockerhub/ghcr orgs for testing in their own forks

So if I want to test the CI by launching an action manually, but pushing to a different org (not affect the official distributed supported EQXM images), then I can change the secret? But how would I do that without being admin, and doesn't it then permanently change it, so now I need an admin to put it back?

Admittedly, testing for actions is kind of miserable.

[detiber]

I'd rather not use a secret here TBH, but it's the only way that I could figure out how to override the value on a per-org basis, so that users can run/publish/test using their own quay/dockerhub/ghcr orgs for testing in their own forks

So if I want to test the CI by launching an action manually, but pushing to a different org (not affect the official distributed supported EQXM images), then I can change the secret? But how would I do that without being admin, and doesn't it then permanently change it, so now I need an admin to put it back?

Admittedly, testing for actions is kind of miserable.

So, basically, the secrets only exist for this repository. If a user wanted to test on their fork, they would define their own secrets there. Since their fork is under their personal account, they have admin permissions to add secrets there.

[detiber]

As a more concrete example, when testing this in my fork, I configured DOCKER_ORG to detiber, and QUAY_ORG to detiber, and that allowed me to test everything against container repos that I owned.

[deitch]

Oh, I get it. So you can test on your own fork, then open the PR when the action looks good.

There seriously has to be a better way to test actions. My instinct says, "oh, just push to a local registry", but that doesn't work when CI is running on GH Actions in their runners.

I guess it looks good, then, but do you mind adding something to the docs about testing, i.e. how to do what you just described? "in your own fork, add secrets, etc."

Then we need @displague to add the necessary secrets before merging.

[detiber]

So, one could use https://github.com/nektos/act for testing locally, but last time I tried it I ran into all sorts of issues when testing and not being able to replicate the github actions environment enough for things like artifacts, caching, and interacting with a ghcr.io registry.

[detiber]

Secrets have been added, I'll work on updating the documentation here shortly

[detiber]

@deitch this should be ready to go now :)

[deitch]

LGTM. Still needs to wait for secrets from @displague ?

[detiber]

LGTM. Still needs to wait for secrets from @displague ?

Nope, I updated the secrets a bit ago after @displague sent them my way.

[deitch]

Cool. Then let's do it!