feat(sentry): 26.5.0 rebase + rename suffix to -ledoent - #3
Merged
Conversation
Add 'gitlab' and 'integrations:gitlab' to supportedProviders array to enable GitLab repositories for Seer Autofix feature.
- Add cloudbuild.yaml for GCP Cloud Build - Add Dockerfile.kencove multi-stage build - Add build-and-push.sh convenience script - Add GitHub Actions workflow for CI/CD - Update AGENTS.md with build instructions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Modifies sentry.conf.py to patch sentry.conf.server module attributes BEFORE the wildcard import. This ensures all code that imports Seer URLs from the server module sees the correct service URLs. Adds SEER_URL and SEER_RPC_SHARED_SECRET environment variable support.
The Explorer-based autofix requires additional endpoints not yet fully implemented in self-hosted Seer. Disable the feature flag to use the legacy /v1/automation/autofix/start endpoint instead. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…gcloud builds submit - WIF provider: github-wlif/providers/github-oidc (was nonexistent github-pool/providers/github-provider) - Service account: github-actions-seer@ (was nonexistent github-actions@) - Branch trigger: 26.1.0-* (was master, which never has the workflow file) - Use gcloud builds submit instead of local docker build (Sentry needs E2_HIGHCPU_32 + 200GB) - Dockerfile: self-hosted/Dockerfile.kencove via cloudbuild.yaml - Add .gcloudignore to exclude .git, node_modules, tests from source upload Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
fixtures/ and tests/ glob matched ALL directories named fixtures/tests throughout the tree, excluding frontend fixture files needed by rspack. Prefix with / to only match root-level directories. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Upstream 26.2.0 removed uwsgi from dependencies. Also align uv version with upstream (0.8.2 → 0.9.28). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ializer Seer returns repositories without organization_id and integration_id, but the DRF serializer required them. This caused 400 errors when the frontend sent back Seer's repo data in preference updates (e.g. setting Cursor handoff). Also adds external_id fallback for repo validation since GitLab repos in Seer have simplified owner/name that differs from the DB format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* ci(sentry): add GHCR public build workflow Publishes ledoent fork to ghcr.io/ledoent/sentry (public) so self-hosted Sentry+Seer deployments can pull without GCP credentials. Builds self-hosted/Dockerfile.kencove for amd64. Free disk on runner before build because Sentry's frontend+backend build is large. Sibling to build-kencove.yml (kept for kencove-prod Cloud Build). * ci(sentry): concurrency + safer disk-cleanup in GHCR workflow Address bugbot findings on the GHCR build workflow: - Add concurrency group keyed on github.ref with cancel-in-progress so rapid pushes (or a force-push) don't race two builds into publishing the same mutable tag. Saves GHA minutes too. - Tighten the 'Free disk space' step: per-path existence check via [ -e "$path" ] && rm -rf, plus drop the blanket '|| true' so a real failure during docker image prune surfaces instead of masking. - Update the runner-RAM comment: GitHub free ubuntu-latest is 16 GB now (post-2024 Larger Hosted Runners refresh), not 7 GB; our first build completed in ~12 min on it. Bump to ubuntu-latest-large only if webpack starts OOMing. * style(ci): prettier — single space before inline comment Sentry's pre-commit prettier hook collapsed a double-space to a single space before the 'full history' comment on fetch-depth. No semantic change.
Upstream 26.5.0's pnpm-lock.yaml uses pnpm's patchedDependencies for zod@4.3.5 (the patch file lives at patches/zod@4.3.5.patch). pnpm install reads the patch contents at lockfile-resolve time, so the directory has to be on disk before that step. Was failing in CI with: ENOENT: no such file or directory, open '/build/patches/zod@4.3.5.patch' The 26.2.0 lockfile didn't have patchedDependencies so the old COPY . . on line 40 (AFTER pnpm install) was sufficient. Adding an explicit COPY patches/ ./patches/ before the install fixes it cleanly without breaking layer caching.
Without this workflow ledoent/sentry@master sits frozen at whatever
commit the fork was created from. Every PR from a *-kencove rebase
branch then shows GitHub's 'this branch has conflicts' against master
— even though the kencove patches themselves don't conflict.
The workflow:
* Runs hourly + on-demand
* Fast-forwards master to upstream/master when possible (the normal
case — kencove patches live on *-kencove branches, never on master)
* Never force-pushes
* If upstream/master can't be FF'd (means master has diverged),
writes a warning to the job summary and exits non-zero so a human
sees it in the Actions tab
Drop-in deployment — no secrets required (GITHUB_TOKEN with
contents:write is auto-provided by the workflow run).
Verified at fork creation time: ledoent/sentry@master is 166 commits
behind getsentry/sentry@master. First run will catch us up.
The ledoent/.github repo has fork-sync-and-digest.yml that already syncs all forks listed in .github/forks.yml via the merge-upstream API. Adding ledoent/sentry to that inventory is the right path — keeps the sync logic in one place and gets the daily digest email alongside the OCA forks.
Upstream 26.5.0 pins .node-version=24.14.0 and packageManager=pnpm@10.30.2. Our Dockerfile was still installing node@22 + pnpm@9 from the 26.2.0 era. pnpm@9 doesn't recognize the new lockfile patchedDependencies format and bails out with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH at frozen install time. Drop-in version bumps; no other Dockerfile changes needed.
…age frontend build
Three iterations failing on the in-Dockerfile rspack frontend build
(typescript loader resolution after upstream's type-loader.ts work
in 26.5.0). Backing off to a much simpler strategy: layer our small
backend patches on top of the pre-built getsentry/sentry:26.5.0
image that upstream's own CI publishes.
This trades a (now-redundant) frontend customization for build
reliability. The kencove fork's only frontend patch was adding
'gitlab' + 'integrations:gitlab' to supportedProviders — and
upstream 26.5.0 already has both in BASE_SUPPORTED_PROVIDERS
natively, with a feature-flag-gated provider mechanism added on
top. So we lose nothing.
What this image still contains:
* Patched src/sentry/seer/endpoints/project_seer_preferences.py
(optional org_id/integration_id + GitLab fallback)
* SEER_URL sed patch on src/sentry/conf/server.py
* self-hosted/sentry.conf.py overlay (seer-explorer flag off)
What's dropped:
* The two-stage frontend-builder + python-runtime build
* uwsgi-dogstatsd remove (upstream image already handles this)
* Node + pnpm install (upstream's image has the frontend bundle)
* sentry.build.main invocation (upstream's image already has dist/)
Dockerfile shrunk from ~170 lines to ~60. Build time goes from
~12 min cold to <30s (just an apt overlay on a pre-built base).
The fork has lived under ledoent/ for some time now; the kencove
branding is legacy. Renames:
* Image tag suffix: ${VERSION}-kencove -> ${VERSION}-ledoent
* Branch pattern: *-kencove -> *-ledoent (GHCR workflow trigger)
* Dockerfile: self-hosted/Dockerfile.kencove -> Dockerfile.ledoent
* Image labels: 'Sentry (ledoent / kencove fork)' -> 'Sentry (ledoent fork)'
Backwards compat:
* The ghcr.io/ledoent/sentry:26.2.0-kencove tag remains accessible
in GHCR (we never delete pushed manifests). Production VM still
pulls that until we cut over.
* The legacy build-kencove.yml Cloud Build workflow + kencove-prod
GAR target keep working — just not the primary path anymore.
Two intentional 'kencove' mentions kept as historical context:
* Comment in build-push-ghcr.yml about the legacy Cloud Build companion
* Comment in Dockerfile.ledoent about the obsolete frontend patch
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.57% |
Backend Test FailuresFailures on
|
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
1 participant
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.
What changed
Rebases the ledoent (formerly kencove) Sentry fork onto upstream
26.5.0and drops thekencovesuffix from the branch + image tag + Dockerfile filename. Replaces #2 (which had the old-kencovehead branch).Final image:
ghcr.io/ledoent/sentry:26.5.0-ledoent(was:26.5.0-kencove).Why this PR is small
The 26.5.0 build went through 4 iterations:
patches/for pnpm installtypescript(upstream added atype-loader.tsthat triggers compile-time resolution)ghcr.io/getsentry/sentry:26.5.0as the base image and overlay our 3 backend patches. Dockerfile shrunk from 170 lines to ~60.The frontend patch (
static/app/components/events/autofix/utils.tsxGitLab providers) is obsolete in 26.5.0 — upstream'sBASE_SUPPORTED_PROVIDERSalready includesgitlabandintegrations:gitlabnatively, with a feature-flag-gated mechanism layered on top. So dropping the in-image frontend rebuild loses nothing.What's in the image
ghcr.io/getsentry/sentry:26.5.0(upstream verbatim)src/sentry/seer/endpoints/project_seer_preferences.py(optionalorg_id/integration_id+ GitLabexternal_idfallback)sedpatch onsrc/sentry/conf/server.py(SEER_DEFAULT_URL →$SEER_URLenv, defaults tohttp://seer:9091)self-hosted/sentry.conf.py(disableseer-explorerfeature flag)Rename details
26.5.0-kencove→26.5.0-ledoent26.5.0-kencove→26.5.0-ledoentself-hosted/Dockerfile.kencove→self-hosted/Dockerfile.ledoent*-kencove→*-ledoentghcr.io/ledoent/sentry:26.2.0-kencoveremains accessible in GHCR for rollback (we never delete pushed manifests).Verification
Image builds and verifies:
Patches verified inside the image:
SEER_DEFAULT_URL = os.environ.get("SEER_URL", ...)✓RepositorySerializerledoent-fork comment present ✓external_idfallback in the POST endpoint ✓Companion PRs
ledoent/sentry@masterin the org-level fork-sync inventory (merged)Rollback
docker compose .envon the VM swapsSENTRY_IMAGEback toghcr.io/ledoent/sentry:26.2.0-kencove. The 26.2.0-kencove image and branch remain immutable.