Release branches in binary builds and functional tests
Omnibus Heptapod (omnibus-heptapod>) is currently our only binary build downstream of the Rails app (heptapod/heptapod>), but that may change in the future.
In Omnibus Heptapod We've long had only branches matching the Rails app development branches: heptapod
, heptapod-stable
etc. This forces the CI/CD scripts in the Rails app to infer the development branch name, which cannot be done reliably from commit information in a release branch (e.g., heptapod-0-38
), hence has to be done using another meta-information: the HEPTAPOD_SERIES
environment variable, which is set in the main CI/CD configuration and is a release critical hazard when juggling with branches (stable branches shift).
The reason for this, despite upstream maintaining release branches in Omnibus GitLab, is that we very seldom had to introduce changes in Omnibus Heptapod after a change of upstream GitLab minor version, and even less to make changes between patch versions (upstream or not), hence it was too heavy to maintain release branches in Omnibus Heptapod. However the price to pay is:
- complexity in Rails release scripts and downstream pipeline triggers.
- systematic conflicts when jumping upstream versions in Omnibus Heptapod (usually just upstream version files, such as
GITLAB_SHELL_VERSION
, changelogs, but sometimes worse than that). - complexity in Omnibus CI/CD configuration (triggering again)
- now that we merge earlier (branching point at rc42 in Omnibus, too), we'll be at greater risk of incompatibilities between upstream versions than when we just merged a final support version.
Note: pipeline triggering is a relatively recent addition, especially from Rails to Omnibus
From Heptapod 0.38 onwards, we'll try the following approach:
- Release branches in Omnibus Heptapod:
heptapod-0-38
etc. - Heptapod tests will keep its simpler branch names (
default
,stable
) etc, but we'll introduce release branches in there, too, even if for an empty diff most of the times.
Note: the HEPTAPOD_SERIES
environment variable will still be needed in the Rails CI/CD configuration, as it governs the branches in CI images. This could be alleviated with out of repository information (static payload in some web site), but that is bad for build reproducibility).