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.
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:
Generate a new personal access token with the api
scope. Alternatively, generate a maintainer project token for each project with the api
scope.
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"
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