test: Upgrade CI postgresql to v18 #121448

ghost · 2026-08-27T12:50:17Z

Bug: Several CI jobs using devservices up may fail as they lack the explicit volume mount fix for PostgreSQL v18 that is present in the backend-test job.
_{Severity: HIGH}

Suggested Fix

Ensure the configuration in the external sentry-shared-postgres repository on the chore/upgrade-postgres-to-v18 branch correctly handles the new volume mount path for PostgreSQL v18. Alternatively, apply the explicit volume recreation step from the backend-test job to all other CI jobs that depend on the postgres service to ensure consistent behavior.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L252 Potential issue: The upgrade to PostgreSQL v18 changes its data directory path. While the `backend-test` CI job includes an explicit step to handle this by recreating the postgres container with the correct volume mount, other CI jobs like `backend-migration-tests`, `cli`, and `migration` do not have this fix. These jobs rely on a `devservices` configuration from an external `sentry-shared-postgres` repository. If the configuration in that repository's `chore/upgrade-postgres-to-v18` branch has not been updated for the new directory structure, these CI jobs will fail when PostgreSQL tries to start and cannot find its data.

Also affects:

devservices/config.yml:41

ghost · 2026-08-10T06:51:23Z

Bug: The PostgreSQL volume is mounted at /var/lib/postgresql instead of the expected /var/lib/postgresql/data, causing the database to be re-initialized mid-workflow and losing all test setup data.
_{Severity: HIGH}

Suggested Fix

Revert the Docker volume mount path in the docker run command back to -v postgres-data:/var/lib/postgresql/data. This will ensure the restarted container finds the existing database data initialized by devservices and prevents data loss during the CI run.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L252 Potential issue: The CI workflow first initializes a PostgreSQL database using `devservices`, which stores data in the standard `/var/lib/postgresql/data` directory within the `postgres-data` volume. However, a subsequent step in the workflow stops this container and restarts it with the volume mounted at `/var/lib/postgresql` instead. When the new container starts, PostgreSQL looks for its data at `/var/lib/postgresql/data` relative to the new mount point, finds an empty directory, and re-initializes the database from scratch. This erases all the initial database setup, including schema migrations, causing subsequent tests that rely on the database to fail.

Also affects:

devservices/config.yml:41~41

ghost · 2026-08-26T10:15:49Z

Bug: The "Reconnect postgres" CI step hardcodes the Docker volume name as postgres-data, which may not match the volume name created by devservices, potentially causing CI failures.
_{Severity: MEDIUM}

Suggested Fix

Instead of hardcoding the volume name postgres-data, dynamically determine the correct volume name used by the postgres-postgres-1 container. This can be done using docker inspect to find the name of the volume mounted at /var/lib/postgresql and then using that name in the subsequent docker run command. This ensures the correct, initialized volume is always re-mounted.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L252 Potential issue: The CI workflow step "Reconnect postgres" hardcodes the Docker volume name as `postgres-data`. However, the initial PostgreSQL container and its volume are created by `devservices`, which uses a Docker Compose configuration from an external repository. Docker Compose typically prefixes volume names with a project name (e.g., `postgres_postgres-data`). If the actual volume name differs from the hardcoded `postgres-data`, the reconnect step will mount a new, empty volume, causing the database to appear blank and subsequent CI steps to fail.

ghost · 2026-08-26T15:30:10Z

Bug: The PostgreSQL volume mount path in backend.yml is updated for v18, but devservices uses a config from an external repo. A mismatch in mount paths could cause data loss during CI.
_{Severity: HIGH}

Suggested Fix

Verify that the docker-compose.yml file in the chore/upgrade-postgres-to-v18 branch of the sentry-shared-postgres repository uses the same volume mount path (-v postgres-data:/var/lib/postgresql) as the reconnect step in backend.yml. Ensure both changes are coordinated and merged correctly.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L252 Potential issue: The CI workflow first starts PostgreSQL using `devservices up`, which pulls its configuration from the `chore/upgrade-postgres-to-v18` branch of the `sentry-shared-postgres` repository. Later, the workflow reconnects to the database using a `docker run` command defined in `.github/workflows/backend.yml`. This PR updates the reconnect command's volume mount to `-v postgres-data:/var/lib/postgresql`, which is correct for PostgreSQL 18. However, if the configuration in the external `sentry-shared-postgres` repository still uses the old mount path (`/var/lib/postgresql/data`), the two steps will use different volumes. This will cause the database initialized in the first step to be lost, leading to a fresh database initialization on reconnect and subsequent CI test failures.

ghost · 2026-08-27T21:25:03Z

Bug: The "Reconnect postgres" step mounts the volume at /var/lib/postgresql, but the initial devservices up might use the old /var/lib/postgresql/data path, causing data loss during CI.
_{Severity: HIGH}

Suggested Fix

Verify that the chore/upgrade-postgres-to-v18 branch in the sentry-shared-postgres repository has been updated to mount the volume at /var/lib/postgresql for the PostgreSQL 18 service. Ensure both the initial setup and the reconnect step use the same volume mount path.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow's "Reconnect postgres via Unix socket" step remounts the PostgreSQL volume at `-v postgres-data:/var/lib/postgresql`, which is correct for PostgreSQL 18. However, the initial database setup is handled by `devservices up`, which uses configuration from the external `sentry-shared-postgres` repository. If that repository's configuration for the PG18 upgrade still uses the old mount path (`/var/lib/postgresql/data`), the initial database and migrations will be written to a temporary, anonymous volume. When the reconnect step runs, it will discard this anonymous volume and mount the empty named volume `postgres-data`, effectively losing all migrated data and causing subsequent tests to fail.

ghost · 2026-08-28T11:26:15Z

Bug: The hardcoded volume mount -v postgres-data:/var/lib/postgresql may be inconsistent with the path used by devservices up, causing PostgreSQL to fail during the reconnect step in CI.
_{Severity: HIGH}

Suggested Fix

Verify that the sentry-shared-postgres repository's chore/upgrade-postgres-to-v18 branch also mounts the volume to /var/lib/postgresql. If there is a mismatch, update the external repository's configuration to ensure both the initial setup and the reconnect step use the same volume mount point.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The PR updates the PostgreSQL volume mount path to `-v postgres-data:/var/lib/postgresql` in the "Reconnect postgres" CI step to support PostgreSQL v18. However, the initial database setup via `devservices up` relies on configuration from the external `sentry-shared-postgres` repository. If that repository's configuration still uses the old mount path (`/var/lib/postgresql/data`), the database will be initialized in a different location. This mismatch will cause the reconnect step to fail as PostgreSQL won't find its data directory, leading to a CI job failure.

ghost · 2026-08-28T19:39:29Z

Bug: The PostgreSQL volume mount path was changed to /var/lib/postgresql, but the initial database setup might still use the old /var/lib/postgresql/data path, causing data loss during CI.
_{Severity: HIGH}

Suggested Fix

Verify that the external repository branch (sentry-shared-postgres@chore/upgrade-postgres-to-v18) has been updated to mount the PostgreSQL volume at /var/lib/postgresql. This will ensure the mount path is consistent across all steps of the CI workflow.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow was updated to mount the PostgreSQL volume at `/var/lib/postgresql`, which is the correct path for PostgreSQL 18. However, the initial database setup is performed by a `devservices` configuration in an external repository. If that external configuration has not been updated and still uses the legacy mount path (`/var/lib/postgresql/data`), a mismatch will occur during the CI run. The subsequent "Reconnect postgres" step will restart the container with the new mount path, making the initialized test data inaccessible. This will cause the database to appear empty, leading to test failures.

ghost · 2026-08-31T11:21:24Z

Bug: The workflow hardcodes the PostgreSQL volume mount path /var/lib/postgresql, which may be incompatible with the path used by the external sentry-shared-postgres dependency, leading to data loss on reconnect.
_{Severity: MEDIUM}

Suggested Fix

Instead of hardcoding the volume mount path, inspect the original container (started by devservices) to retrieve its volume mount configuration. Re-use this discovered configuration when relaunching the container to ensure the path is always correct and not dependent on an unverified external change.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow stops and restarts a PostgreSQL container, hardcoding the volume mount path to `-v postgres-data:/var/lib/postgresql` to support PostgreSQL 18. However, the initial container is configured by an external `sentry-shared-postgres` dependency. The workflow does not verify that this external dependency uses a compatible volume mount path. If the external configuration from the `chore/upgrade-postgres-to-v18` branch has not been updated to match, the reconnected container will not find the initialized database, causing CI failures. This creates a fragile dependency on an unverified external configuration.

ghost · 2026-08-31T17:52:05Z

Bug: A potential mismatch exists between the PostgreSQL volume mount path in the initial container setup (/var/lib/postgresql/data) and the reconnect step (/var/lib/postgresql), which could cause data loss during CI runs.
_{Severity: HIGH}

Suggested Fix

Verify that the configuration in the sentry-shared-postgres repository on the chore/upgrade-postgres-to-v18 branch also mounts the PostgreSQL volume at /var/lib/postgresql. If it uses the old path, it must be updated to match the path in the backend.yml workflow to ensure consistency.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow first starts a PostgreSQL container using a configuration from the `sentry-shared-postgres` repository. A later step reconnects to this database by starting a new container using the same volume. The pull request updates the reconnect step's volume mount path to `/var/lib/postgresql` to support PostgreSQL 18. However, if the initial container setup defined in the external `sentry-shared-postgres` repository still uses the old mount path (`/var/lib/postgresql/data`), the reconnected container will not find the existing data. This would cause it to initialize a new, empty database, leading to failures in all subsequent database-dependent tests.

Also affects:

devservices/config.yml:41

ghost · 2026-09-01T13:06:44Z

Bug: The "Reconnect postgres" CI step hardcodes the volume name postgres-data, which may not match the volume name used by the new external PostgreSQL configuration, causing CI failures.
_{Severity: MEDIUM}

Suggested Fix

Instead of hardcoding postgres-data, dynamically inspect the running postgres container to get its actual volume name and use that in the reconnect step. Alternatively, verify that the sentry-shared-postgres branch uses the postgres-data volume and add documentation to enforce this convention.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The "Reconnect postgres" step in the CI workflow at `.github/workflows/backend.yml:253` hardcodes the Docker volume name as `postgres-data`. The pull request changes the `devservices` configuration to use a branch from an external repository, `sentry-shared-postgres:chore/upgrade-postgres-to-v18`. If this external configuration uses a different volume name for the PostgreSQL container, the reconnect step will fail. It would attempt to use a new, empty volume named `postgres-data` instead of reusing the existing volume with the database data, leading to initialization errors and CI failures.

ghost · 2026-09-01T14:47:05Z

Bug: The CI workflow reconnects to a PostgreSQL container with a new volume mount path. If the initial container from sentry-shared-postgres uses a different path, the database will be lost.
_{Severity: MEDIUM}

Suggested Fix

Verify that the configuration in the sentry-shared-postgres repository's chore/upgrade-postgres-to-v18 branch mounts the PostgreSQL volume at /var/lib/postgresql. This ensures consistency with the volume mount path used in the reconnect step in the backend.yml workflow.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow first starts a PostgreSQL container via `devservices` using configuration from the `sentry-shared-postgres` repository. It then stops this container and restarts it with a volume mount path defined in `.github/workflows/backend.yml` as `-v postgres-data:/var/lib/postgresql`. Due to a breaking change in PostgreSQL 18, the data directory path has changed. If the configuration in the `sentry-shared-postgres` repository's `chore/upgrade-postgres-to-v18` branch has not also been updated to use the new mount point, it will be inconsistent with the reconnect step. This will cause the reconnected container to not find the existing database, leading to CI test failures.

Also affects:

devservices/config.yml:41~41

ghost · 2026-08-07T13:32:27Z

Bug: The CI workflow's PostgreSQL volume mount path is updated for v18, but it doesn't validate the actual image version, risking startup failure or silent data reset with older images.
_{Severity: CRITICAL}

Suggested Fix

Enforce the PostgreSQL version dependency. Either explicitly use a specific v18+ image tag instead of dynamically inspecting the running container, or add a step to verify the PostgreSQL version from the image before re-running the container with the new volume path. This ensures the volume mount path is compatible with the image being used.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L253 Potential issue: The CI workflow in `.github/workflows/backend.yml` changes the PostgreSQL volume mount path to be compatible with PostgreSQL v18. However, the actual PostgreSQL image version is determined dynamically from a branch specified in `devservices/config.yml` without any validation. If this process results in an older (pre-v18) PostgreSQL image being used, the container will either fail to start or silently initialize a new, empty database because the volume mount path will be incorrect for that version. This could cause CI jobs to fail or to pass incorrectly with tests running against an empty database.

Also affects:

devservices/config.yml:41~41

ghost · 2026-08-24T18:14:07Z

Bug: The CI step for restarting PostgreSQL uses a volume path only valid for PostgreSQL 18+, creating a fragile dependency on an unverified external image version.
_{Severity: LOW}

Suggested Fix

Add a verification step to the CI workflow to inspect the $PG_IMAGE and confirm it is a PostgreSQL 18+ version before restarting the container. Alternatively, make the volume mount path conditional based on the detected image version. This will make the CI workflow more resilient and prevent failures caused by out-of-sync dependencies.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L249-L255 Potential issue: The CI workflow was updated to restart PostgreSQL with a volume mount path (`-v postgres-data:/var/lib/postgresql`) that is only correct for PostgreSQL version 18 or newer. The Docker image (`$PG_IMAGE`) is pulled from an external feature branch in the `sentry-shared-postgres` repository. If this external branch does not provide a PostgreSQL 18+ image, the container will be started with an incorrect volume path. While a newly added socket check will cause the CI job to fail loudly rather than silently, this change introduces a fragile dependency where CI can break due to an un-synced change in an external repository.

Also affects:

devservices/config.yml:41~41

ghost · 2026-08-26T11:39:41Z

Bug: The script recreates the Postgres container without preserving its original environment variables. If the initial PGDATA path differs from the new container's default, it can lead to data loss.
_{Severity: HIGH}

Suggested Fix

When recreating the container, inspect the original container to capture its environment variables (especially PGDATA) and re-apply them to the new docker run command. This ensures the recreated container uses the same data directory as the original, preventing data loss.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L249-L255 Potential issue: The CI workflow stops and recreates the `postgres-postgres-1` container. During this process, it captures the Docker image name but fails to preserve the environment variables from the original container. The initial container, created by `devservices`, might have a specific `PGDATA` path configured. The recreated container, lacking this environment variable, will fall back to the PostgreSQL 18 default `PGDATA` path. This mismatch in data directory paths will cause the new container to not find the existing database, leading to re-initialization and data loss within the CI job.

ghost · 2026-08-28T16:40:38Z

Bug: The PostgreSQL container restart in the CI workflow doesn't preserve the PGDATA environment variable, which could cause the new container to fail to find the existing database.
_{Severity: MEDIUM}

Suggested Fix

To ensure the restarted container can find the database, preserve the PGDATA environment variable. Inspect the original container to get its PGDATA value and explicitly pass it to the new container during the docker run command in the "Reconnect postgres via Unix socket" step. This makes the restart process more robust and less dependent on the image's default configuration.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L250-L256 Potential issue: The CI workflow restarts the PostgreSQL container to switch to a Unix socket connection. This restart process does not preserve environment variables from the original container. Specifically, the `PGDATA` variable, which tells PostgreSQL where to find its data files, is not passed to the new container. The new PostgreSQL 18 image, referenced by the `chore/upgrade-postgres-to-v18` branch, likely uses a version-specific data directory. Without the `PGDATA` variable being explicitly set, the restarted container will fall back to its default setting, which may not align with where the data was initially created on the volume, causing the database to fail to reconnect.

ghost · 2026-08-31T23:00:30Z

Bug: The Postgres container is recreated without the PGDATA environment variable, which can cause data inaccessibility or loss in CI due to path mismatches in PostgreSQL 18.
_{Severity: HIGH}

Suggested Fix

Explicitly pass the PGDATA environment variable to the docker run command in the "Reconnect postgres via Unix socket" step. This ensures the recreated container uses the same data directory as the original container. For example, add -e PGDATA=/var/lib/postgresql/18/docker or dynamically retrieve the value from the original container before stopping it.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/backend.yml#L250-L256 Potential issue: The CI workflow recreates the PostgreSQL container in the "Reconnect postgres via Unix socket" step. However, the `docker run` command used for recreation does not pass the `PGDATA` environment variable. The PostgreSQL 18 Docker image uses a version-specific default for `PGDATA` (e.g., `/var/lib/postgresql/18/docker`). If the original container used a specific `PGDATA` path, the recreated container will default to a different one. This mismatch will cause the container to either fail to start or initialize a new, empty database, leading to data loss within the CI run and causing subsequent tests to fail.

ghost · 2026-08-06T14:33:59Z

Bug: The devservices/config.yml points the postgres dependency to a temporary feature branch, chore/upgrade-postgres-to-v18, which will likely be deleted after merging.
_{Severity: MEDIUM}

Suggested Fix

After the changes in the chore/upgrade-postgres-to-v18 branch are merged into the main branch of the sentry-shared-postgres repository, update devservices/config.yml to point the postgres dependency back to branch: main.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: devservices/config.yml#L41 Potential issue: The `devservices/config.yml` file is configured to use a temporary feature branch, `chore/upgrade-postgres-to-v18`, for the `sentry-shared-postgres` dependency. Feature branches are typically deleted after being merged. Once this branch is deleted from the upstream repository, the `devservices up` command will fail for any developer trying to set up their local environment, as it will be unable to clone the specified branch. This will break the local development setup process.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

ghost · 2026-08-07T16:54:49Z

Temporary feature branch dependency pin

High Severity

postgres in devservices/config.yml is pinned to the temporary branch chore/upgrade-postgres-to-v18 instead of main. If this lands, local devservices and CI depend on that branch; once it is merged or deleted, postgres startup fails for everyone.

^{Reviewed by Cursor Bugbot for commit e323490. Configure here.}

ghost · 2026-08-26T14:21:07Z

Bug: The devservices/config.yml file points to a temporary external branch, which will break devservices up when the branch is deleted.
_{Severity: HIGH}

Suggested Fix

Before merging this pull request, the branch reference for the postgres dependency in devservices/config.yml should be reverted to main. This should only be done after the external chore/upgrade-postgres-to-v18 branch has been merged into its repository's main branch to ensure the required changes are present.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: devservices/config.yml#L41 Potential issue: The configuration file `devservices/config.yml` is being modified to point the `postgres` dependency to a temporary feature branch (`chore/upgrade-postgres-to-v18`) in an external repository. If this pull request is merged as-is, and that temporary branch is subsequently deleted as part of a normal development workflow, any invocation of `devservices up` will fail. This will break local development environments and multiple CI jobs, including `backend-migration-tests`, `cli`, `migration`, and `monolith-dbs`, which depend on this service.

ghost · 2026-08-28T20:15:27Z

Bug: The devservices/config.yml points the sentry-shared-postgres dependency to a temporary branch, chore/upgrade-postgres-to-v18, which will likely be deleted, causing devservices up to fail.
_{Severity: HIGH}

Suggested Fix

Once the changes in the chore/upgrade-postgres-to-v18 branch are merged into main in the sentry-shared-postgres repository, this configuration should be reverted to point back to the main branch to prevent breaking local development setups.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: devservices/config.yml#L41 Potential issue: The `devservices/config.yml` file is being updated to point the `sentry-shared-postgres` dependency to a temporary branch, `chore/upgrade-postgres-to-v18`. This branch is likely to be deleted after its changes are merged into `main`, as is standard practice. Once the branch is deleted, any developer running `devservices up` will encounter a failure because the tool will attempt to check out a non-existent branch. This will break the local development environment for most modes, preventing developers from starting their services.

ghost · 2026-08-31T18:29:17Z

Bug: The postgres service in devservices/config.yml points to a temporary feature branch, chore/upgrade-postgres-to-v18, which will likely be deleted, breaking local development and CI.
_{Severity: HIGH}

Suggested Fix

The postgres service configuration in devservices/config.yml should be updated to point to a stable branch, such as main, after the changes from the chore/upgrade-postgres-to-v18 branch are merged in the sentry-shared-postgres repository.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: devservices/config.yml#L41 Potential issue: The `devservices/config.yml` file configures the `postgres` service to use the `chore/upgrade-postgres-to-v18` branch. Unlike other services which point to stable branches like `main` or `master`, this branch is temporary. Once this feature branch is merged and deleted from its repository, any attempt to run `devservices up` will fail. This will block all local development and break multiple CI workflows that rely on this configuration, as there is no fallback mechanism to a stable branch.

-Original file line number
+Diff line change
@@ Expand Up / @@ -249,7 +249,7 @@ jobs: @@
               docker run -d --name postgres-postgres-1 \
                 --network devservices --label orchestrator=devservices \
                 -p 127.0.0.1:5432:5432 \
-                -v postgres-data:/var/lib/postgresql/data \
+                -v postgres-data:/var/lib/postgresql \
                 -v /tmp/pg-sock:/var/run/postgresql \
                 -e POSTGRES_HOST_AUTH_METHOD=trust -e POSTGRES_DB=sentry \
                 "$PG_IMAGE" postgres \
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -38,7 +38,7 @@ x-sentry-service-config: @@
           description: Shared instance of postgres used by sentry services
           remote:
             repo_name: sentry-shared-postgres
-            branch: main
+            branch: chore/upgrade-postgres-to-v18
             repo_link: https://github.com/getsentry/sentry-shared-postgres.git
         redis:
           description: Shared instance of redis used by sentry services
@@ Expand Down @@

Uh oh!

test: Upgrade CI postgresql to v18 #121448

Are you sure you want to change the base?

Uh oh!

test: Upgrade CI postgresql to v18 #121448

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

ghost Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ghost Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ghost Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ghost Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 7, 2026

Choose a reason for hiding this comment

Temporary feature branch dependency pin

Uh oh!

Uh oh!

ghost Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

ghost Aug 31, 2026

Choose a reason for hiding this comment