Tag for auto-deploy introduces confusion when building other components
When we settled on our auto-deploy tag, we utilized the sha of both our gitlab
and omnibus-gitlab
stable branches or green builds as a way to capture a snapshot of where we are at that moment in time. #325 (comment 172375468)
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+<omnibus sha>
In the future, we are going to start needing to tag our CNG builds and the above strategy does not make sense. Being that both CNG and omnibus serve a similar purpose (building of GitLab) we need to have a way to differentiate our tag to account for either of these without introducing confusion and complexity in our release toolset.
Current State
- This is were we are today as we implement the need to build CNG in order to deploy our current hybrid infrastructure of both omnibus and helm chart deployments
- Using:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+<omnibus sha>
- #577 (comment 265956565)
-
-
We don't know which CNG sha was used to build our Kubernetes components -
+
This is an iterative step that allows us to not be blocked in building CNG
Future State
Option 1
Proposal
- Drop the omnibus sha entirely, template:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>
- Example tag:
12.7.201912202205+efc6b1836b8
Plus/Down sides
-
+
Simpler -
-
We loose build visibility- We won't know which omnibus or CNG component was utilized for the build
Option 2a
Proposal
- Send differing tags, for omnibus we maintain our current tag structure
- When building CNG, we have a matching capability to send the a similar tag structure, but simply replace omnibus with CNG for JUST that component
- templates:
- For omnibus builds:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+<omnibus sha>
- For CNG builds:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+<CNG sha>
- For omnibus builds:
- Example tags:
- For omnibus builds:
12.7.201912202205+efc6b1836b8.b0a14ae7b76
- For CNG builds:
12.7.201912202205+efc6b1836b8.1328054a7ca
- For omnibus builds:
Option 2b
Proposal
- Send differing tags, for omnibus we maintain our current tag structure with an additional annotation
- When building CNG, we have a matching capability to send the a similar tag structure, but simply replace omnibus with CNG for JUST that component
- templates:
- For omnibus builds:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+omnibus-<omnibus sha>
- For CNG builds:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+cng-<CNG sha>
- For omnibus builds:
- Example tags:
- For omnibus builds:
12.7.201912202205+efc6b1836b8+omnibus-b0a14ae7b76
- For CNG builds:
12.7.201912202205+efc6b1836b8+cng-1328054a7ca
- For omnibus builds:
Plus/Down sides
-
-
More complex- Yet another tag to be aware of
- Build tools will need to be aware of which component this is to send the correct data to deployer
-
+
We'll have an easier time determining which omnibus/CNG component was built -
?
what tooling will need to be adjusted to account for this extra metadata inline with the tag?
Option 3
Proposal
- Build a solution that is To Be Determined (named VERSION in the rest of this issue description) into our versioning of components which is a part of &113 (closed)
- Example may be that we have a VERSION repo which contains all our component versions that are known to work succinctly together
- This repo itself will be versioned, for which we can utilize this as part of our tag, whether that be a semver or sha
- For all builds:
MAJOR.MINOR.<timestamp>.<VERSION SHA>
orMAJOR.MINOR.<timestamp>.<VERSION semver>
- Example tag:
12.7.20191202205+abcdef12345
or12.7.20191202205+0.0.1
Plus/Down sides
-
-
We need to build the VERSION repo -
+
We'd utilize the VERSION repo to quickly determine what components were used across all aspects of the GitLab build
Option 4
Proposal
- Add the tag to the tail end of our current configuration
- template:
MAJOR.MINOR.<timestamp>+<gitlab-ee sha>+<omnibus sha>+<CNG sha>
- Example tag:
12.7.201912202205+efc6b1836b8.b0a14ae7b76+1328054a7ca
Plus/Down sides
-
+
easy to do -
+
this provides a clear differentiation with what is built across our current toolset -
-
this creates a really long tag, are there limitations we may run into somewhere in our tool chain? -
-
If we go with this method, it's simply a bandaid until we have yet another component we need to account for in the future.
Edited by John Skarbek