Problem/Motivation
Currently we have a very large number of variables in the template. Some make sense as they have to be present for GitLab to make decisions before any custom code executes, others less so.
On a cursory glance:
- CORE_STABLE
- CORE_SECURITY
- CORE_SECURITY_PREVIOUS_MINOR
- CORE_SUPPORTED
- CORE_MINOR
- CORE_NEXT_MINOR
- CORE_MAJOR_DEVELOPMENT
- CORE_PREVIOUS_STABLE
- CORE_PREVIOUS_SECURITY
- CORE_LEG_STABLE
- CORE_LEG_PATCH
- CORE_LEG_MINOR
These are intended to be used in conjunction with _TARGET_CORE and are only needed for composer or other uses inside of a running container. These could be converted to a lookup table. If the value of $_TARGET_CORE matches a value in the table we pull the version and use that, if not we pass through the value raw.
- CORE_PHP_MIN
- CORE_PHP_MAX
- CORE_PHP_NEXT
- CORE_NEXT_PHP_MIN
- CORE_NEXT_PHP_MAX
- CORE_NEXT_PHP_NEXT
- CORE_PREVIOUS_PHP_MIN:
- CORE_PREVIOUS_PHP_MAX:
If we work with DrupalCi Enviroments,we could take the images with these as constants. This could allow us to use these as constant strings. We could still keep one global "PHP_IMAGE_NAME" variable to allow easy overriding in GitlabCi runs without modifying the we would track the images closer to release dates. A maintainer owner could still always override with a specific release by setting $_TARGET_PHP_VERSION to a specific version or tag name.
- CORE_MYSQL_MIN
- CORE_MYSQL_MAX
- CORE_MYSQL_NEXT
- CORE_MYSQL_TEST_DEFAULT
- CORE_LEG_MYSQL_MIN
- CORE_LEG_MYSQL_MAX
- CORE_LEG_MYSQL_NEXT
- CORE_LEG_MYSQL_TEST_DEFAULT
- CORE_MARIADB_MIN
- CORE_MARIADB_MAX
- CORE_MARIADB_NEXT
- CORE_MARIADB_MIN_TEST_DEFAULT
- CORE_LEG_MARIADB_MIN
- CORE_LEG_MARIADB_MAX
- CORE_LEG_MARIADB_NEXT
- CORE_LEG_MARIADB_MIN_TEST_DEFAULT
- CORE_PGSQL_MIN
- CORE_PGSQL_MAX
- CORE_PGSQL_NEXT
- CORE_LEG_PGSQL_MIN
- CORE_LEG_PGSQL_MAX
- CORE_LEG_PGSQL_NEXT
- CORE_SQLITE_MIN
- CORE_SQLITE_MAX
- CORE_SQLITE_NEXT
- CORE_LEG_SQLITE_MIN
- CORE_LEG_SQLITE_MAX
- CORE_LEG_SQLITE_NEXT
These would be the same as PHP, make them a part of the image name.
The list above is itself 48 variables, or roughly 55% of the set variables when running a pipeline.
The biggest negatives I can see to this are:
- It may make using external images (like woodby4drupal) a bit harder, however Drupal Dedicated repo's (or mirrors) could add the tags to make it easier to work with gitlab_templates. Worst case a maintainer could set values and use monitoring tools to open MR's to change tags as needed.
- When you pin a project to a specific gitlab_templates release the PHP Containers would still move, however that already occurs to some degree as we only have two tags (prod and dev) for each container line.
Steps to reproduce
Proposed resolution
Convert many variables to constants that are resolved outside of GitLabCi
Remaining tasks
Discuss if this is possible
Work with necessary repo's to implement docker image naming changes
User interface changes
Decrease in variables visible when running a pipeline.
API changes
Removal of lookup variables.
Require using a lookup table inside running container.
Data model changes
New lookup table