Story

As a member of the RHDH Docs team on Mac, I want to run ARM-compatible pre-release builds of RHDH using RHDH Local so that I can quickly test it locally and document its features before it is released.

Background

Right now, for testing out pre-releases with RHDH Local, users need to switch to quay.io/rhdh/rhdh-hub-rhel9:1.y, which are not compatible with ARM.

We have community builds that are ARM-compatible, but those builds are triggered from the main branch (providing a `next` image tag) or when a given Git tag is pushed (providing a `1.y` image tag). But `main` can quickly diverge from the release branches.

Similar to these `next` tags, the idea here is, therefore, to trigger such pre-release community builds from the release branches as well, so we can also have image tags like `next-1.y` from these release-1.y branches.

This may also be useful to other folks wishing to evaluate a given pre-release community build on their ARM machines.

Acceptance Criteria

• update the next-build-image workflow to be triggered on release branches as well
• publish `next-1.y` image tags from a given `release-1.y` branch
• update the RHDH Local documentation to mention this. See https://github.com/redhat-developer/rhdh-local/blob/main/additional-config-guides/container-image-guide.md#changing-the-container-image
• if we're only planning to do builds from the 1.y (and 1.y-1 branches (eg., currently 1.7 and 1.6) then we need a mechanism in the downstream tagRelease.sh script to update the branch target(s) every time we create a new branch via a new change in the existing generated PR that bumps versions in main
  • we could start with just the ONE stable branch for 1.y = 1.7, and see if there's a need to add builds for next-1.y-1 = next-1.6 as well
  • for now, we'll assume each commit in the release-1.y branch will trigger a new `next-1.y` build + tag.

Based on the 1.7 branch, we get about 2 commits a day in stable branches, so this seems so far to be a reasonable amount of building (vs. the 1-per-day crontab triggering on main, where we get 4-6 commits a day.

So for now having 2 next-1.y tags created a day is reasonable. We can re-evaluate if this is bogging down the system in future.