ref(ci): parallel devservices startup and more robust bootstrap-snuba#112381
Merged
ref(ci): parallel devservices startup and more robust bootstrap-snuba#112381
Conversation
setup-sentry takes ~2min per backend test shard, with ~90s spent on devservices (Docker image pulls + container health checks). This all runs serially after Python/venv setup, even though image pulls don't depend on the venv at all. Add a setup-devservices composite action that: - Parses uv.lock (via tomllib) for the pinned devservices version - Installs it into an isolated /tmp venv using system Python - Starts `devservices up` in the background immediately after checkout The full setup-sentry venv restore (~19s) now runs concurrently with Docker image pulls. A wait script polls for completion with proper error handling and timeout. Also extract the Snuba per-worker bootstrap into a two-phase script: - Phase 1 (early): Polls for ClickHouse readiness and runs the expensive `bootstrap --force` while devservices is still bringing up remaining containers - Phase 2 (after devservices): Stops the default Snuba container and starts per-worker API instances Net saving: ~25-35s per shard depending on container startup order.
Apply the same early-devservices pattern from the backend test change. Acceptance tests have several minutes of webpack/node build between checkout and setup-sentry, so devservices will be fully ready by the time the venv is set up — the entire ~90s of container startup becomes free.
github-actions
bot
added
the
Scope: Backend
Apply the same overlap pattern to every workflow that uses setup-sentry: backend-migration-tests, cli, api-docs, api-url-typescript, migration, monolith-dbs, migrations, migrations-drift, openapi, and openapi-diff.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e8287ab. Configure here.
- Use strict shell (set -euo pipefail) at action level - Fix set -e preventing exit code file from being written in subshell - Add 10-minute timeout to Snuba bootstrap wait loop - Move devservices start after chartcuterie build in acceptance - Revert migrations/migrations-drift (checkout master first, action doesn't exist there yet)
joshuarli
changed the title
This reverts commit c8766fe.
rbro112
reviewed
Apr 7, 2026
This reverts commit 4325402.
This reverts commit 6d20efb.
joshuarli
changed the title
mchen-sentry
reviewed
Apr 7, 2026
| @@ -0,0 +1,38 @@ | |||
| name: 'Early Devservices' | |||
Member
There was a problem hiding this comment.
nit: This action + wait.sh could live inside setup-sentry instead of being a separate action. setup-sentry already has skip-devservices and devservices-timeout-minutes inputs. We can add a parallel-devservices mode to let it start the background process early (before venv setup) and
wait at the end (where it currently runs devservices up synchronously). I notice we're repeating the same 3-step pattern across all the 10 or so jobs, but just parallel-devservices: 'true' on the existing setup-sentry step would be a lot easier
Member
Author
There was a problem hiding this comment.
i would like to cut down on the boilerplate too but we'd lose most of the benefit for acceptance because webpacking requires setup-sentry and we want to be pulling stuff while webpacking
Member
There was a problem hiding this comment.
sure, let's just tackle this later.
mchen-sentry
approved these changes
Apr 7, 2026
george-sentry
pushed a commit
that referenced
this pull request
Apr 9, 2026
…#112381) `setup-sentry` takes ~2min per backend and acceptance test shard - most of this overhead is ~90s container setup this intros a new `setup-devservices` composite action which `devservices up` in the background immediately after checkout, no setup-sentry required cause we can just parse `devservices` version from uv.lock with stdlib python i'm observing ~30-40s saved per acceptance test shard and similar numbers for backend and the rest
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
setup-sentrytakes ~2min per backend and acceptance test shard - most of this overhead is ~90s container setupthis intros a new
setup-devservicescomposite action whichdevservices upin the background immediately after checkout, no setup-sentry required cause we can just parsedevservicesversion from uv.lock with stdlib pythoni'm observing ~30-40s saved per acceptance test shard and similar numbers for backend and the rest
example: https://github.com/getsentry/sentry/actions/runs/24096487514/job/70296340867
time to start running acceptance tests is 1m50s
before: ~2m30s https://github.com/getsentry/sentry/actions/runs/24096224167/job/70295443714
backend: ~45s saved!
before https://github.com/getsentry/sentry/actions/runs/24096491312/job/70296457386 2m45s before tests run
after https://github.com/getsentry/sentry/actions/runs/24096896697/job/70297892709: 2m before tests run
also applies to the rest of the setup-sentry callers: backend-migration-tests, cli, api-docs, api-url-typescript, migration, monolith-dbs, migrations, migrations-drift, openapi, openapi-diff