Previously under DrupalCi the majority of image usage was controlled by the DA. To this design images were either Production or Dev images.
With the migration to GitLab the Images have transitioned to a status where they are now a base for CI operations. The DA no longer directly controls all operations, maintainers are encouraged to extend/modify the CI process as needed to fit their project needs.
The DrupalCI images are currently the foundational base of the gitlab_templates repository which is encouraged as the base for configuring GItLab based CI on G.D.O.
This transition us to a state where the DrupalCi Environment images are now being used in a manner that depends upon reliably signaling changes and maintainers needing the tools to control adoption of those changes.
As an example the work on #3387737: Split PHP image into php(cli/apache) and yarn(node/nightwatch) → was promoted from the dev images to the tagged production images yesterday (Context: during a US holiday which for many continues until Monday). This change can/does break CI testing for some projects.
Thankful my projects just end up not running Code Coverage and this created a soft fail, however if I had adopted Mutation testing (which depends upon code coverage) it would have been a hard fail.
While I was aware this work was in-progress, and suspected I would need to eventually update my Gitab template files there was no advance warning that this change would occur yesterday and that I needed to update all my projects before the holiday.
Addtionaly for point-in-time testing (needing to back and test older dev cycles) having reliably retrievable images would also help.
The gitlab_templates project could handle most of the issues regarding when/how to upgrade to a new major and how to announce it, the images just need to be tagged in a way that allows the templates to do so.
Naming like drupalci/apache-php-8.2:X.Y.Z (with a side label of drupalci/apache-php-8.2:latest pointing to the latest in the highest major and drupalci/apache-php-8.2:X pointing to the highest version in the specified major) would likely be sufficient for templates to refer to these images.
How we want to sync the majors/minors would be the biggest question.
I would suggest that at least the majors be synced in such a manner that one could use the major specific tag across all currently maintained CI images without expecting errors to occur due to tooling (in other words: the only errors we should expect would be related to the version of PHP and not the rest of the image.)
N/A
Adopt SEMVER type numbering for images being pushed to Docker Hub,
Any changes that could break existing installs (such as removing programs, removing libraries, disabeling modules, etc) be done as a major release.
Any changes adding new features (adding new modules, tools, upgrading versions of tools without changing their interface methods, etc) be done as a Minor release
Any changes that only fix faults in the existing images be done as a patch release.
TBD
None
Adds a definition of the images being considered API.
None
Active
Container Build Process
As an aside, all these same issues apply to gitlab_templates too. There we want our cake and eat it too. We want sites to automatically pickup changes to the templates but occasionally we break stuff, either by mistake or on purpose.
Opened #3404175: Adopt (semver) versioning for gitlab_templates → to discuss the gitlab_templates equivalent of this.
