Correct Procedure to update version

[gino8080]

Please can you describe the steps to make a correct update procedure?

my docker-compose is like this

version: '3.6'
services:
  gitlab:
    image: 'zengxs/gitlab:latest'
    restart: always
    container_name: gitlab
    hostname: '*********.it'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://**********.it'

        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        letsencrypt['enabled'] = false
        gitlab_rails['gitlab_protocol'] = 'https'
        gitlab_rails['gitlab_https'] = false
    expose:
      - '80'
    ports:
      - '8081:80'
      - '2222:22'
    networks:
      - int
    volumes:
      - './config:/etc/gitlab'
      - './data:/var/opt/gitlab'
      - './logs:/var/log/gitlab'

networks:
  int:
    external: true

I tried stopping and restarting container but did not worked

[zengxs]

To update your GitLab instance, you only need to change the image version in your docker-compose.yml file. For example, if you want to upgrade to version 16.4.0-ce, follow these steps:

1. Modify the docker-compose.yml file to change the image line to:

   image: zengxs/gitlab:16.4.0-ce
   

2. Stop all containers and then restart them.

   docker compose down   // stop container
   docker compose up -d  // restart container
   

Please note that you can only upgrade from one minor version to the next (e.g., from 16.4.x to 16.5.x). If you need to upgrade across multiple minor versions (e.g., from 16.4.x to 16.7.x), you must do so step by step: 16.4.x → 16.5.x → 16.6.x → 16.7.x. This is a limitation of GitLab itself. For more information, please refer to the official documentation: GitLab Upgrade Paths.

[gino8080]

Thank you, I will retry following these steps.

I'm doing a minor upgrade from v17.4.1 to latest (v17.5)

I tried using these steps before:

1. docker pull zengxs/gitlab:latest
2. then later docker-compose down
3. then docker-compose up

but after an infinite logs the system didn't started correctly apparently without any error...

I saw a new folder with ssl and some certificates inside the mapped ./config, but I'm using it behind another nginx proxy with correct certificates, so I don't know what's happened :(

[zengxs]

Thank you for the update. It sounds like you might be experiencing an issue during the upgrade process. Without logs, I can only make some guesses. It’s possible that GitLab is in the middle of a migration during the upgrade, which can sometimes take over 10 minutes.

Could you please provide the logs from the GitLab container? This will help me diagnose the issue further.

[HandSonic]

To update your GitLab instance, you only need to change the image version in your file. For example, if you want to upgrade to version , follow these steps:docker-compose.yml``16.4.0-ce

1. Modify the file to change the image line to: docker-compose.ymlimage: zengxs/gitlab:16.4.0-ce
2. Stop all containers and then restart them. docker compose down // stop container docker compose up -d // restart container

Please note that you can only upgrade from one minor version to the next (e.g., from to ). If you need to upgrade across multiple minor versions (e.g., from to ), you must do so step by step: → → → . This is a limitation of GitLab itself. For more information, please refer to the official documentation: GitLab Upgrade Paths.16.4.x``16.5.x``16.4.x``16.7.x``16.4.x``16.5.x``16.6.x``16.7.x

I've referred to gitlab's upgrade route with the intention of upgrading (17.1.8 => 17.3.7 => 17.5.5 => 17.8.7 => 17.11.3 => 18.0.1), but I didn't find a docker image with the corresponding version, e.g., 17.3.x doesn't have the exact matching version number, is it ok to use another version number?

[zengxs]

@HandSonic

It's understandable that you couldn't find exact Docker image matches for every point in GitLab's upgrade path. I generally don't maintain patch versions for previous minor releases once a new minor version is out, due to limited resources.

You can usually upgrade using the closest available image within the same minor version (e.g., any 17.3.x image).

Always ensure you have a complete data backup before starting your upgrade. This will allow you to revert if any issues arise. If you encounter problems with the existing 17.3.x images, you could also try building the 17.3.7 image yourself from the 17.3.x commit history.