Add a command to push to OCI registries

[kubasobon]

Towards giantswarm/roadmap#391

Checklist

• Make yourself familiar with following readme sections:
  • Coding Standards.
  • Development.
  • Design and Goals.
• ⚠️ Update changelog in CHANGELOG.md.

[MarcelMue]

Generally looking good to me - just a small question :)

[MarcelMue]

Maybe a stupid question: Where does helm actually come from here? Is it just installed by default? And should we verify that the version is recent enough?

[kubasobon]

architect-orb uses architect's Dockerfile as a base image. We install a bunch of binaries in that Dockerfile, including helm. I've recently updated architect (https://github.com/giantswarm/architect/pull/728/files), and architect-orb is already using the latest release.

[rossf7]

LGTM

[ubergesundheit]

Sorry to chime in ininvited, please ignore me if my concerns don't make any sense..

Why introduce a new command? Couldn't this also work with the existing commands/jobs by specifying the catalog as oci:// url? I am asking because this seems to skip existing linting and checking steps in place with architect and app-build-suite based pushing.

[kubasobon]

@ubergesundheit: Existing commands "push" to catalogs by making a Git commit in a specified repository. This command on the other hand will use helm to publish a chart to an OCI registry. That feels different enough to me to warrant a separate command. There is another command used to push with ABS enabled: https://github.com/giantswarm/architect-orb/blob/master/src/commands/package-and-push-with-abs.yaml.

I'll add an OCI + ABS version as well as an OCI registry login to this PR before re-requesting reviews.

[ubergesundheit]

I'll add an OCI + ABS version as well as an OCI registry login to this PR before re-requesting reviews.

Thats good! TBH a solution where the git based pushing would be moved into a separate command and then making the pushing command/mechanism configurable in the existing jobs would be less confusing, but this is also fine for me.

[kubasobon]

Thats good! TBH a solution where the git based pushing would be moved into a separate command and then making the pushing command/mechanism configurable in the existing jobs would be less confusing, but this is also fine for me.

Bundling the two sounds like a solid idea. I'll add it to the proposed PR as well.

[MarcelMue]

It still makes sense to me - I struggle a bit to understand how this looks like in a project in the end, but that's a minor issue.

[kubasobon]

@MarcelMue This PR adds a new command set for pushing charts to OCI registries (two new commands). It also adds two switches to the push-to-app-catalog job. push_to_appcatalog, enabled by default, runs existing commands and publishes charts to GitHub. push_to_oci_registry, disabled by default, runs new commands and publishes charts to the AzureCR OCI registry.

If we merge this and craft a release, everything will remain the same due to the defaults. If we flip the switches we can change behavior to push to OCI as well or push to it exclusively.

Do we want push_to_oci_registry right away?

[MarcelMue]

I think it makes sense to release first with the switch disabled and then try it in select repositories. WDYT?

[kubasobon]

I agree 👨‍🔬

[kubasobon]

It works!

[kubasobon]

@ubergesundheit PTAL. I think this covers all your requests. Push to the catalogs hosted on GitHub happens by default. All one has to do to push to the OCI registries is add a push_to_oci_registry: true to .circleci/config.yml of an app.

workflows:
  version: 2
  build-and-push:
    jobs:
      - architect/push-to-app-catalog:
          context: "architect"
          executor: "app-build-suite"
          name: "package and push chart to app catalog"
          app_catalog: "giantswarm-catalog"
          app_catalog_test: "giantswarm-test-catalog"
          chart: "hello-world-app"
          # Trigger job on git tag.
          filters:
            tags:
              only: /^v.*/
          push_to_oci_registry: true

[ubergesundheit]

Thanks :) Some addition to the docs would have been nice

[kubasobon]

Sure, on it.