v1.7.5

Security

• postgres:17 was rebuilt upstream; the pin moved from sha256:f4c66b820c6f… to sha256:d74eeac9a635…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.4

Changed

• The freshness check has its own workflow, Pin Freshness. It ran inside Deployment Verification, whose badge is the one at the top of this README. Across the fleet, nine red runs in ten were a pin one version behind - which the fleet's triage moves within the day - and a reader cannot tell that from a stack that does not boot. The badge now says whether the stack boots. The job itself is unchanged.

• gitlab/gitlab-ee:19.4.0-ee.0 moved to 19.4.1-ee.0. GitLab publishes no
  release notes for a patch in this line, and the commit list is largely
  "Add latest changes from gitlab-org/security/gitlab@19-4-stable-ee" — security
  backports, which are disclosed later and by design carry no detail now. That
  is a reason to move, not to wait.

  Asked of the registry, the two images are identical in every field that
  changes behaviour: user, entrypoint, command, working directory, ports,
  volumes, healthcheck and the whole environment. Nothing in the contract
  between the container and this compose file moved.

• gitlab/gitlab-runner stays at ubuntu-v19.4.0. The ubuntu-v19.4.1 tag
  is announced but not published — the registry answers 404 for it. The runner
  is supported against a server of the same or newer minor, so 19.4.0 against
  19.4.1 is a supported pair, and the freshness check stays red until upstream
  pushes the tag. That red is upstream's to clear, not this repository's.

Changed

• gitlab/gitlab-ee:19.4.0-ee.0 moved to gitlab/gitlab-ee:19.4.1-ee.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 19.4.0 -> 19.4.1

Verdict: NEEDS ATTENTION — no usable release notes exist for this range, and several commits are explicitly security backports ("Add latest changes from gitlab-org/security/gitlab@19-4-stable-ee"), which typically fix vulnerabilities without public detail until later disclosure.

Breaking changes

• none found in the notes — the notes contain no descriptive content at all, only commit titles. Given that GitLab's practice is to withhold detail on security fixes at release time, the absence of a described breaking change here is not evidence that none exists.

Variables

• none — nothing in the commit list touches configuration surface, and the compose file / .env.example require no changes for this bump.

Data and dependencies

• none stated. The compose file pins Postgres at 17@sha256:f4c66b8... independently of the GitLab version; the notes (such as they are) name no required companion-service version, so there is no pin mismatch to flag.

Before applying

• Take a GitLab backup before upgrading (standard practice for any GitLab point release, not something these commits specifically call for).
• Since at least four of the seven commits are labeled as security backports with no changelog detail, check GitLab's own security-release advisories for 19.4.1 by hand before treating this as routine — the commit titles alone don't say what was fixed.
• After updating, watch the gitlab container's health check and gitlab-ctl reconfigure output on first start as usual for a patch bump.

Notes read

• Compare API output for v19.4.0...v19.4.1 on gitlabhq/gitlabhq: 7 commits, no release notes found for either tag. No UPGRADING/BREAKING_CHANGES/CHANGELOG document was supplied for this range, so GitLab's own security advisory pages for 19.4.1 should be checked manually.

v1.7.3

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:1c32e7c36820… to sha256:24841fe2de73…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.2

Security

• postgres:17 was rebuilt upstream; the pin moved from sha256:67f41722b7a8… to sha256:f4c66b820c6f…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.1

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:1c32e7c36820…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.0

Changed

• GitLab 19.4. The runner moved to 19.4.0 first, on its own, which left it
  a minor ahead of the server it is meant to track. This moves the server to
  match, and the two are pinned in lockstep again.

  First boot runs GitLab's database migrations, and they are not reversible.
  That is the whole of the disruption, and it is why this is a minor here and
  not a patch. Take the backup this template's own gitlab-backup.sh produces
  before pulling it on a live deployment.

  What was checked rather than assumed: GitLab's required upgrade stops for 19
  are 19.2, 19.5, 19.8 and 19.11, so 19.3 to 19.4 is a direct hop with no
  intermediate stop. GitLab 19.x requires PostgreSQL 17, minimum and maximum,
  and this template pins postgres:17. The upstream review could not read
  release notes for the range, because GitLab does not publish them to GitHub,
  and said so rather than guessing; the deploy job brought the previous release
  up first on the volumes this one upgrades, ran the migrations, answered
  through Traefik and produced a backup before this landed.

Changed

• gitlab/gitlab-runner:ubuntu-v19.3.2 moved to gitlab/gitlab-runner:ubuntu-v19.4.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. First boot runs GitLab's database migrations and they are not reversible. Take the backup gitlab-backup.sh produces first. .env and the data volumes are otherwise untouched.

The deploy job on the pull request brought the previous release up on the volumes this one then upgraded, ran the migrations, answered through Traefik and produced a backup before this was cut.

Full history in CHANGELOG.md.

v1.6.7

v1.6.6 announced GitLab 19.3.2 and shipped 19.3.1. This ships it.

The v1.6.6 commit touched CHANGELOG.md and nothing else. Fleet triage builds its substitution from the version the freshness check reports, which is 19.3.1, while the image tag is 19.3.1-ee.0, so it matched nothing in the compose file. The lines after that loop ran regardless: the report claimed a bump, the changelog announced one, the CI gate passed because nothing had changed, and the release went out over a file still pinning the old image.

A gate proves the stack boots. It cannot prove a change landed when the change never happened.

This moves the pin for real, to 19.3.2-ee.0 at the digest Docker Hub serves for it. Triage no longer writes a changelog entry or cuts a release for a bump that edited no file; that guard went in alongside this release.

Nobody who took v1.6.6 received a different GitLab than v1.6.5 gave them. They receive 19.3.2 here.

Upgrading: ./update.sh.

v1.6.6

Changed

• gitlab/gitlab-ee:19.3.1-ee.0 moved to gitlab/gitlab-ee:19.3.2-ee.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 19.3.1 -> 19.3.2

Verdict: NEEDS ATTENTION — release notes could not be retrieved, so no upstream-confirmed safety claim can be made for this upgrade.

Breaking changes

• Not available: the release notes source returned HTTP Error 404: Not Found for gitlab/gitlab-ee. No breaking-change text exists to quote for this range.

Variables

• none found in the notes (notes unreadable)
• Independent of the notes: the compose file's x-images block currently pins GITLAB_IMAGE_VERSION:-19.3.1-ee.0 as the default — this is the "From" version and must be bumped to 19.3.2-ee.0 (with the matching digest) as part of applying this upgrade, whether or not the notes required any other variable change.

Data and dependencies

• none confirmed from notes (unreadable)
• The compose file pins postgres:17 for this deployment. Since the 19.3.2 release notes could not be read, it is not confirmed whether GitLab 19.3.2 changes its minimum/recommended PostgreSQL version. This must be checked by hand before applying — if 19.3.2's own documentation names a PostgreSQL requirement this compose file does not meet, that supersedes any other finding here.

Before applying

• Read GitLab's own upgrade documentation for the 19.3.1 → 19.3.2 range directly (GitLab publishes an "Upgrading GitLab" / version-specific upgrade notes page separate from GitHub releases, since gitlab/gitlab-ee is not distributed via GitHub releases) — check specifically for:
  • required PostgreSQL version for 19.3.2
  • any listed background migrations or post-deployment migrations for this range
  • any deprecated/removed omnibus gitlab_rails[...] or nginx[...] configuration keys used in this compose file's GITLAB_OMNIBUS_CONFIG block
• Take a GitLab backup before upgrading (gitlab-backup.sh per this repo's README, or gitlab-rake gitlab:backup:create) — standard practice for any GitLab version bump, independent of what the notes say.
• Update the compose file's GITLAB_IMAGE_VERSION default (and digest) from 19.3.1-ee.0 to 19.3.2-ee.0 — a version bump does not happen automatically from a git pull alone; the pin has to be edited.
• After confirming compatibility, monitor the gitlab container's health check and logs through startup (start_period: 240s) since Omnibus runs migrations on container start.

Notes read

• None. GitHub releases for gitlab/gitlab-ee returned HTTP 404 for this range. No UPGRADING/BREAKING_CHANGES/CHANGELOG excerpt was supplied for 19.3.1 → 19.3.2 either. Check GitLab's official update documentation (docs.gitlab.com "Upgrading GitLab" pages for the 19.3 series) by hand before proceeding.

v1.6.5

Changed

• gitlab/gitlab-ee:19.3.1-ee.0 moved to gitlab/gitlab-ee:19.3.2-ee.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 19.3.1 -> 19.3.2

Verdict: NEEDS ATTENTION — the upstream release notes could not be retrieved, so this GitLab EE minor bump is going in unreviewed; treat it as unverified until checked by hand.

Breaking changes

• Unknown: release notes were not available (see below). GitLab EE patch releases (x.y.1 -> x.y.2) are usually security/bug-fix only, but this cannot be confirmed from the notes here.

Variables

• none identified — no notes to check against. The compose file's own variables (GITLAB_DB_PASSWORD, GITLAB_HOSTNAME, GITLAB_URL, TRAEFIK_ACME_EMAIL, TRAEFIK_HOSTNAME, TRAEFIK_BASIC_AUTH) are unchanged from what a working 19.3.1 deployment would already have set.

Data and dependencies

• Postgres is pinned in the compose file at postgres:17@sha256:67f41722b7a8cbdb868a44a4995c846eddfdc2973bccb291ce937dce88ad5675 (x-images.postgres). Since the release notes could not be read, there is no confirmation either way that 19.3.2 still supports Postgres 17 — this must be checked manually against GitLab's own documented Postgres compatibility for 19.3.x before assuming the pin is still valid.
• No irreversible-migration or removed-default information available from notes.

Before applying

Since the notes are missing, before applying this bump the host operator should manually check:

1. GitLab's own release page/changelog for 19.3.2 (gitlab.com/gitlab-org/gitlab, "Releases" or the CHANGELOG.md in that tag) for any migration or breaking-change entries — the GitHub mirror's release API returned 404, so pull from GitLab's own project instead.
2. GitLab's UPGRADING/BREAKING_CHANGES doc (docs.gitlab.com "Upgrade path" and the version-specific upgrade notes) covering the 19.3.1 → 19.3.2 range specifically.
3. Confirm Postgres 17 (currently pinned) is still the supported/required database version for 19.3.2.
4. Take a GitLab backup before upgrading, per standard GitLab practice: docker compose -p gitlab exec gitlab gitlab-backup create (or the repository's own gitlab-backup.sh, referenced in .env.example under GITLAB_BACKUPS_PATH), and snapshot/back up the gitlab-postgres, gitlab-config, gitlab-data volumes.
5. After confirming no breaking changes, bump GITLAB_IMAGE_VERSION/digest in the compose file's x-images.gitlab line (or override via .env GITLAB_IMAGE_TAG) to 19.3.2, then docker compose pull gitlab && docker compose up -d gitlab and watch docker compose logs -f gitlab for migration completion before considering the upgrade done.

Notes read

• Release notes for gitlab/gitlab-ee 19.3.1 -> 19.3.2 could not be read: GitHub releases endpoint returned HTTP Error 404: Not Found. No UPGRADING/BREAKING_CHANGES/CHANGELOG excerpt was supplied for this range either. All statements above are based solely on the compose file and .env.example, not on verified upstream release content.

v1.6.4

Changed

• gitlab/gitlab-ee:19.3.1-ee.0 moved to gitlab/gitlab-ee:19.3.2-ee.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 19.3.1 -> 19.3.2

Verdict: NEEDS ATTENTION — upstream release notes could not be retrieved, so this upgrade cannot be verified from source; treat it as unreviewed until checked by hand.

Breaking changes

• Not available: the release notes for gitlab/gitlab-ee 19.3.2 could not be read (HTTP Error 404: Not Found). No breaking-change claim can be made or ruled out from this source.

Variables

• none found (no notes to check against; compose/.env.example show no variable changes required by this bump — GITLAB_IMAGE_VERSION default simply moves from 19.3.1-ee.0 to whatever 19.3.2-ee.0 digest is set)

Data and dependencies

• none confirmed — but note the compose file pins postgres:17 (GITLAB_POSTGRES_IMAGE_TAG / GITLAB_POSTGRES_IMAGE_VERSION) as the companion database for GitLab. Since GitLab's own release notes for 19.3.2 could not be read, there is no confirmation this patch still supports PostgreSQL 17. This must be checked manually before or immediately after the upgrade (see below).

Before applying

• Manually check GitLab's own release/upgrade documentation for 19.3.2 (the GitLab docs site or CHANGELOG.md in the gitlab-org/gitlab repo, since the GitHub releases API returned 404 — gitlab-ee is not typically released via GitHub tags/releases).
• Specifically confirm:
  • Required PostgreSQL version for 19.3.2 (compare against the pinned postgres:17).
  • Any background migrations or schema changes flagged for this version (GitLab often requires letting migrations finish before the next upgrade).
  • Any deprecated/removed omnibus gitlab_rails[...] or nginx[...] config keys used in this compose file's GITLAB_OMNIBUS_CONFIG block.
• Take a full GitLab backup (gitlab-backup.sh per this repo's README) and a Postgres data volume snapshot before upgrading, as standard practice for any GitLab version bump, patch or not.
• After upgrade, check docker compose logs gitlab for migration completion and verify /etc/gitlab/initial_root_password flow and health check pass before considering the upgrade complete.

Notes read

• None. GitHub releases for gitlab/gitlab-ee returned 404; no UPGRADING/BREAKING_CHANGES/CHANGELOG excerpt was supplied for this range. All conclusions above are based solely on the compose file and .env.example, not on verified upstream release content.