Fallback to Docs site main if the stable branch doesn't exist yet
What does this MR do and why?
The docs hugo_build CI job runs a Docs website (Hugo) build to validate docs changes in the MR. This job needs to clone and use the same version of the Docs website as the version of GitLab it's testing for.
This MR fixes an edge case: if someone tries to backport something to gitlab before the Docs website has cut its release yet, the job fails (like what happened here). This can happen in the few days between GitLab cutting its release branch (a few days before the release) and the Docs site cutting its release branch (release day).
If this comes up, we should use the docs site main (pre-release) branch to test the docs changes.
See gitlab-org/technical-writing/docs-gitlab-com#450 (closed)
Test jobs
We're emulating MRs to different GitLab target branches by hard-coding BRANCH_NAME in the CI job (like this).
| GitLab target branch | Expected Docs site branch | Example |
|---|---|---|
Unreleased stable version: 20-2-stable-ee
|
main |
https://gitlab.com/gitlab-org/gitlab/-/jobs/11298851708 |
Released stable version: 18-2-stable-ee
|
18.2 |
https://gitlab.com/gitlab-org/gitlab/-/jobs/11298816832 |
Feature branch: sarahgerman-hugo-test-branch-fallback
|
main |
https://gitlab.com/gitlab-org/gitlab/-/jobs/11298913420 |
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.