Add gitlab_branch parameter to gdk install

What does this merge request do and why?

Closes #3239 (closed)

Allows specifying a GitLab branch to checkout during installation:

gdk install gitlab_branch=my-feature-branch

This is useful when you need to install GDK with a specific GitLab branch from the start, avoiding the need to run gdk switch after installation which re-runs migrations and other setup steps.

Motivation: When setting up GDK for development on a specific feature branch, the current workflow requires running gdk install (which clones master) followed by gdk switch my-branch (which re-runs migrations). This is inefficient because migrations run twice and extra time is spent on setup steps that need to be redone.

Implementation:

  • Add gitlab.clone_branch config setting (empty by default, meaning master)
  • Add gitlab_branch parameter parsing in install.rb
  • Translate gitlab_branch=X to gitlab_clone_branch=X for Make
  • Update Makefile.gitlab.mk to use GIT_REVISION when cloning (same pattern as other components)
  • Add comprehensive tests
  • Add documentation differentiating from gitlab.default_branch (which is used by gdk update and gdk switch)

How to set up and validate locally

  1. Clone and set up the test environment:

    git clone https://gitlab.com/gitlab-org/gitlab-development-kit.git gdk-test
    cd gdk-test
    mise trust
    git checkout mk/gitlab-branch-install-parameter
    cat << EOF > gdk.yml
    ---
    tool_version_manager:
       enabled: true
    EOF
    make bootstrap
  2. Test command line parameter:

    gdk install gitlab_branch=mk/org-migration-target

    Verify the output shows Cloning https://gitlab.com/gitlab-org/gitlab.git (branch: mk/org-migration-target)

  3. Test gdk.yml config (alternative method):

    gdk config set gitlab.clone_branch mk/org-migration-target
    gdk install

    Verify the clone uses the specified branch.

  • #3238 (closed) - Follow-up to add this parameter to the one-line install script

Impacted categories

The following categories relate to this merge request:

Merge request checklist

  • This MR references an issue describing the change.
  • This change is backward compatible. If not, include steps to communicate to users.
  • Tests added for new functionality. If not, raise an issue to follow-up.
  • Observability added/updated (logging, metrics, tracing).
  • Documentation added/updated.
  • Announcement added for notable changes.
  • gdk doctor test added.
Edited by Michael Kozono

Merge request reports

Loading
Loading