GitLab Next

We created the current auto-deploy behavior during a one-week onsite in early 2019. The result was rapid iteration on a hard problem in a short time and as a result, we got something working but accumulated some technical debt in the process.

As we begin adding more complexity to the auto-deploy process with CNG images, and auto-deploying other components like Gitaly, this problem will only get worse, so I think it would be prudent to address some of the problems now.

1. PassingBuild is misnamed. This class, along with the generically-named Commits, handles multiple things:
   1. Find a passing build
   2. Trigger an Omnibus auto-deploy
      1. Create a deployer tag to deploy the Omnibus package after it's built
   3. Trigger a CNG auto-deploy => !841 (merged)
   4. Trigger a generic branch tagging => !859 (merged)
2. PassingBuild takes a project argument, because at the time we needed to find a passing build (or do one of the other things above) in CE or EE. Now that we only care about EE, this is needless complexity. => #390 (closed)
3. PassingBuild takes a ref argument. This is never not the current auto-deploy branch, so it's extra complexity.
4. ComponentVersions does three independent things: => !1059 (merged)
   1. Deal with the component versions defined by the gitlab-rails project (EE)
      1. Fetch the version strings defined by the various *_VERSION files
   2. Deal with the component versions defined by the Omnibus project
      1. Check if the versions defined in Omnibus differ from those we fetched from EE
      2. Commit to Omnibus with the versions fetched from EE
   3. Deal with the component version variables defined by the CNG image
      1. Normalize the version strings used by Omnibus into formats usable by the image
      2. Fetch and parse the Gemfile for EE
      3. Add version strings for specific gems from EE
      4. Check if the versions defined in the image differ from those we fetched from EE
      5. Commit to the image with the versions fetched from EE
5. ComponentVersions takes a project argument, because at the time we needed to find a versions (or do one of the other things above) in CE or EE. Now that we only care about EE, this is needless complexity. => #394 (closed)

cc @gitlab-org/deliveryf