feat: enable forks to release and publish to custom quay registries

[reggie-k]

Closes #25300

Changes made:

• Enabled forking to a repo with any name and not just argo-cd (there was an explicit assumption in the workflows that the forked repo is called argo-cd)
• Enabled publishing images from forks to custom registries, by setting the following GitHub Actions env vars on forks: IMAGE_NAMESPACE, IMAGE_REPOSITORY, GHCR_NAMESPACE and GHCR_REPOSITORY. IMAGE_ vars have default values of the official argo-cd repos, to keep the upstream image publishing process as was. GHCR_NAMESPACE has the default value of {{ github.repository }}, that resolves to upstream upon upstream build and to fork upon fork build.
• Enabled creating custom argo-cd releases on forks, by setting the GitHub Actions env var ENABLE_FORK_RELEASES on the fork
• Local make manifests and make manifests-local now requires setting IMAGE_REGISTRY explicitly.
• Fixed a regression after moving to oracle-vm-16cpu-64gb-x86-64 CNCF runner - when we switched to it for e2e tests, they stopped running on forks cause forks have no access to this CNCF runner.

How are the official Quay + GHCR repos protected from accidental pushes from forks:

• Official Argoproj Quay: Fork maintainers are required to override the default argoproj IMAGE_NAMESPACE, otherwise the publishing steps will be skipped. Even if the fork maintainers have the creds to the official Quay registry, and they configure them on the fork, the pushing step will be still skipped.
• Official Argoproj GHCR: GHCR_NAMESPACE defaults to {{ github.repository }}, which resolves to the fork GHCR. An explicit attempt to configure GHCR_NAMESPACE to argoproj/* will result in the step pushing the image and the attestation to GHCR being skipped.

A concern about release process performed on forks by Argo CD Approvers (people with write access to argo-cd official repo)

• For Argo CD approvers that maintain custom forks they wish to release from, there is an edge case upon which the custom argo-cd release can run by mistake on the official repo instead of on the fork. This can happen if running ./hack/trigger-release.sh v.... upstream on the fork repo. The correct way to run is ./hack/trigger-release.sh v.... origin.
• Since to the best of my knowledge ./hack/trigger-release.sh is never invoked automatically but always manually, I added a user prompt for upstream release process, that would require human input before proceeding if upstream was specified, to reduce the chance of such a mistake.

Bonus impact:

It is now possible to test the release process on any fork before performing the actual release, meaning we have a test environment for the release process. Here is an example of 3.3.0-rc1 release on my personal fork, created while testing this PR (nothing was published to Argo CD official repo or registries while creating it): https://github.com/reggie-k/argo-cd/releases/tag/v3.3.0-rc1.

Checklist:

• [ ] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• [ ] The title of the PR states what changed and the related issues number (used for the release note).
• [ ] The title of the PR conforms to the Title of the PR
• [ ] I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• [ ] I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• [ ] Does this PR require documentation updates?
• [ ] I've updated documentation as required by this PR.
• [ ] I have signed off all my commits as required by DCO
• [ ] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• [ ] My build is green (troubleshooting builds).
• [ ] My new feature complies with the feature status guidelines.
• [ ] I have added a brief description of why this PR is necessary and/or what this PR solves.
• [ ] Optional. My organization is added to USERS.md.
• [ ] Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

[bunnyshell[bot]]

:x: Preview Environment deleted from Bunnyshell

Available commands (reply to this comment):

• :rocket: /bns:deploy to deploy the environment

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :warning: Please upload report for BASE (master@de79e6a). Learn more about missing BASE report. :warning: Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #25365   +/-   ##
=========================================
  Coverage          ?   62.56%           
=========================================
  Files             ?      352           
  Lines             ?    49746           
  Branches          ?        0           
=========================================
  Hits              ?    31123           
  Misses            ?    15648           
  Partials          ?     2975           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[rumstead]

This is awesome! It took me quite a few tries to fix goreleaser a while back and I had to "test in prod".

[reggie-k]

@rumstead yessss! The only gotcha is that I couldn't test the actual logic when the repo IS the upstream repo, so some surprises may still be upon the next release, but hopefully not too many.

[choejwoo]

Great work on this! As I was going through the PR, I suddenly became curious. Are there specific criteria for when to upgrade Ubuntu from 22.04 to the next LTS, 24.04? Since 22.04 still has over a year of support left, I was wondering how the timing for upgrades is usually decided.

[reggie-k]

Great work on this! As I was going through the PR, I suddenly became curious. Are there specific criteria for when to upgrade Ubuntu from 22.04 to the next LTS, 24.04? Since 22.04 still has over a year of support left, I was wondering how the timing for upgrades is usually decided.

Thanks! We currently use Plucky Puffin release (25.04), upgrading from the LTS for security reasons. Not sure we have a specific policy update though. Is there anything particular in the PR that surfaced the question?

[choejwoo]

Great work on this! As I was going through the PR, I suddenly became curious. Are there specific criteria for when to upgrade Ubuntu from 22.04 to the next LTS, 24.04? Since 22.04 still has over a year of support left, I was wondering how the timing for upgrades is usually decided.

Thanks! We currently use Plucky Puffin release (25.04), upgrading from the LTS for security reasons. Not sure we have a specific policy update though. Is there anything particular in the PR that surfaced the question?

Ah, I just asked because I saw the Ubuntu 22.04 image tag in runs-on. I was curious about how the image used for Testcontainers and the runner image used in the workflow are managed. Thanks for the explanation!

[reggie-k]

Added a fix to a regression: after moving to oracle-vm-16cpu-64gb-x86-64 CNCF runner - when we switched to it for e2e tests, they stopped running on forks cause forks have no access to this CNCF runner. Now forks can run e2e tests like before.