Dogfooding GitLab Releases

1. You are here:
2. Engineering
3. Development Department
4. Ops Sub-department
5. Release Group
6. Dogfooding GitLab Releases

On this page

• Dogfooding GitLab Releases
• History
• How does this process work?
• FAQ
  • Why does this process live in gitlab-com/www-gitlab-com?
  • Where are the tests for this process?
• Troubleshooting
• Testing locally

Dogfooding GitLab Releases

One way we live out our dogfooding value is by using our own releases feature to publish GitLab's monthly releases. These releases can be seen in the gitlab and gitlab-foss projects.

History

Before we began dogfooding our releases feature, we published releases to https://about.gitlab.com/releases/. Once we introduced the automated dogfooding process, we replaced the content of this page with a link to the GitLab project's releases page.

How does this process work?

At a high level, the automated release creation process works like this:

1. Product and engineering managers follow the release post process to create *.yml files in the gitlab-com/www-gitlab-com repo for each new feature that should be announced (example).
2. A pipeline step in the gitlab-com/www-gitlab-com repo executes the update_project_releases_page rake task.
   1. All *.yml files are parsed and rendered as Markdown for use as the description for each release
   2. A request is made to the appropriate project (either gitlab-org/gitlab or gitlab-org/gitlab-foss) using the release REST API to fetch all the existing releases
   3. Each release generated from the *.yml files is compared to the list of existing releases. If the release doesn't yet exist (or if an existing release's content has been changed), the release is created (or updated) using the release REST API.

FAQ

Why does this process live in gitlab-com/www-gitlab-com?

Mostly for simplicity and historical reasons. As mentioned above, we previously published releases to https://about.gitlab.com/releases/. This process was automated by some code in gitlab-com/www-gitlab-com (this file, in particular) which parsed all the *.yml files and combined their content into a Ruby hash for each release.

The new dogfooding process was able to reuse this existing code; as a result, it only concerns itself with rendering each Ruby hash to Markdown and updating the project's releases through the API.

Where are the tests for this process?

As of this writing, this process is untested 😕

Troubleshooting

If something goes wrong, here are some things to check:

• Ensure the tag exists in the repository and is formatted correctly (e.g. v14.1.0-ee for EE, or v14.1.0 for FOSS)
• Ensure the group milestone exists in the gitlab-org group and is named correctly (e.g. 14.1)
• Ensure the API token is available as an environment variable named GITLAB_BOT_TOKEN

Both the tag and milestone must exist before the process attempts to create the release.

Note that the pipeline step that runs this process is currently set to allow_failure: true, so any errors that occur won't prevent the pipeline from succeeding.

Testing locally

Local testing can be accomplished using the Release Dogfooding Test Group, which mimics the structure of the gitlab-org group. It contains two test projects: GitLab EE Releases Test Project, which mimics gitlab-org/gitlab and GitLab FOSS Releases Test Project, which mimics gitlab-org/gitlab-foss.

This test group/projects have been pre-populated with the necessary tags and milestones for the process to succeed.

To test using these projects:

1. Generate a new personal access token with the api scope. Alternatively, generate a maintainer project token for each project with the api scope.

2. Temporarily update update_gitlab_project_releases_page.rake to point to these test projects:

   diff --git a/lib/tasks/update_gitlab_project_releases_page.rake b/lib/tasks/update_gitlab_project_releases_page.rake
   index 08d9c4d70be..4dfade35691 100755
   --- a/lib/tasks/update_gitlab_project_releases_page.rake
   +++ b/lib/tasks/update_gitlab_project_releases_page.rake
   @@ -7,8 +7,13 @@ require "gitlab"
   require_relative "../../generators/releases"
   
   namespace :release do
   -  GITLAB_FOSS_PROJECT_ID = 13083
   -  GITLAB_EE_PROJECT_ID = 278964
   +  # GITLAB_FOSS_PROJECT_ID = 13083
   +  # GITLAB_EE_PROJECT_ID = 278964
   +
   +  # TEMP
   +  GITLAB_FOSS_PROJECT_ID = 28654245
   +  GITLAB_EE_PROJECT_ID = 28654237
   +
   
      CORE = "core"
      STARTER = "starter"
   

3. Execute the following commands. Replace <token here> with the token generated above.

   # For FOSS
   GITLAB_BOT_TOKEN=<token here> bundle exec rake release:foss:update_project_releases_page
   
   # For EE
   GITLAB_BOT_TOKEN=<token here> bundle exec rake release:ee:update_project_releases_page
   

4. Check the two Releases pages to see if the process resulted in the correct changes:
   • gitlab-ee-releases-test-project
   • gitlab-foss-releases-test-project
5. Before commiting your changes, undo the changes made in step #2.