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

To test this script locally:

1. Fork the GitLab EE project to your personal namespace.
2. Fork the GitLab FOSS project to your personal namespace
3. Generate a new personal access token with the api scope. Alternatively, generate a maintainer project token for each project with the api scope.

4. Set environment variables:

    export GITLAB_BOT_TOKEN="YOUR TOKEN"
    export GITLAB_EE_PROJECT_ID="YOUR GITLAB FORK ID"
    export GITLAB_FOSS_PROJECT_ID="YOUR GITLAB FOSS FORK ID"
   

5. Populate your projects with necessary milestones:

    bundle exec pry
   

    require "gitlab"
    gitlab_client = Gitlab.client(endpoint: "https://gitlab.com/api/v4", private_token: ENV['GITLAB_BOT_TOKEN'])
    (13..18).each { |major| (0..13).each { |minor| gitlab_client.create_milestone(ENV['GITLAB_EE_PROJECT_ID'], "#{major}.#{minor}") } }
    (13..18).each { |major| (0..13).each { |minor| gitlab_client.create_milestone(ENV['GITLAB_FOSS_PROJECT_ID'], "#{major}.#{minor}") } }
   

6. Update the releases pages.

    # For FOSS
    bundle exec rake release:foss:update_project_releases_page
   
    # For EE
    bundle exec rake release:ee:update_project_releases_page
   

7. Check the two Releases pages to see if the process resulted in the correct changes on your test projects.