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.
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.
At a high level, the automated release creation process works like this:
*.yml
files in the gitlab-com/www-gitlab-com
repo for each new feature that
should be announced
(example).gitlab-com/www-gitlab-com
repo
executes the update_project_releases_page
rake
task.
*.yml
files are parsed and rendered as Markdown for use as the
description for each releasegitlab-org/gitlab
or
gitlab-org/gitlab-foss
)
using the release REST
API to fetch all
the existing releases*.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.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.
As of this writing, this process is untested 😕
If something goes wrong, here are some things to check:
v14.1.0-ee
for EE, or v14.1.0
for FOSS)gitlab-org
group and is named
correctly (e.g. 14.1
)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.
To test this script locally:
api
scope. Alternatively, generate a maintainer project token for each project with the api
scope.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"
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}") } }
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