Skip to content
  • gitlab
  • configuration

Reason for this post

Normally a gitlab upgrade is no big deal, and things just work. This time around however I had to modify two things before it would work. I'm running it via the omnibus docker image (gitlab/gitlab-ee:17.0.0-ee.0) and don't usually have to do anything to upgrade versions.

  • Runners
  • Postgres

Runners

I had been using the old gitlab runner register to create new runners when new vm's are created via automated scripts. 17.0 deprecated the feature I was using, and while I could re-enable them they're going to be removed in 18.0 so I figured just do it now.

Basically it just meant moving the --tag-list and a few other things. Full list here.

Instead of running those in the register command passed to gitlab-runner, I had to create the runner via the curl command below, then pass the output token to the gitlab runner register command instead

create_runner_17_changes() {
  apk add curl yq || true
  RUNNER_TOKEN=$(curl --silent --request POST --url "${GITLAB_URL}/api/v4/user/runners" \
  --data "runner_type=instance_type" \
  --data "description=$UNIQUE_TAG Deployment Runner" \
  --data "locked=false" \
  --data "access-level=not_protected" \
  --data "run-untagged=true" \
  --data "tag-list=Deploy,POS-$NEW_ID_NUMBER,$UNIQUE_TAG" \
  --data "maintenance-note=What a pain in the arse!" \
  --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}")  
}
Then the new token to pass to the gitlab-runner register command is extracted with 
FINAL_TOKEN=$(yq e '.token' <<< "$RUNNER_TOKEN")

Postgres

The postgres database gave me an invalid user problem when I first tried to upgrade. For some reason the omnibus upgrade didn't automatically trigger a postgres upgrade, but even if it did it probably would have failed to how large it was.

The following command allowed the postgres update to happen (This had to be run with the original gitlab-ee:16.11.1-ee-0 image running. I was able to simple change the docker-compose.yml back to 16.11.1-ee-0 to run this command and then switch back to 17.0.0)

docker exec -it gitlab gitlab-ctl pg-upgrade --timeout=1d2h3m4s5ms

Due to a large database I had to add the --timeout to the command, or it failed part way through the db upgrade.

The above command was found on the gitlab website in a support document.

Final Tip

In 17.0 we can finally use extensions in the vscode webide, but it's disabled by default for now. In order to enable it first run:

docker exec -it gitlab gitlab-rails console
This can take quite a long time, so wait for it. When it's ready it should look like the following:

root@gitlab:/home/deadc0de# docker exec -it gitlab gitlab-rails console
--------------------------------------------------------------------------------
 Ruby:         ruby 3.1.5p253 (2024-04-023 revision 1945f8dc0e) [x86_64-linux]
 GitLab:       17.0.0-ee (8c75d0bf4a4) EE
 GitLab Shell: 14.35.0
 PostgreSQL:   14.11
------------------------------------------------------------[ booted in 58.06s ]
Loading production environment (Rails 7.0.8.1)
irb(main):001:0>

Then enable the feature flags with the following commands:

Feature.enable(:web_ide_oauth)
Feature.enable(:web_ide_extensions_marketplace)

And finally you can open your user preferences on the gitlab webpage, search for "integrations" (it's at the very bottom of your preferences page) and enable it.