Sentry release tracking for production (git sha + deploy markers)
维护者通常 1 天内回复
@vprashrex 已经在做这个了。
开始于 2026年10月10日。
评估
这个 Issue 还没有评估数据。
描述
Describe the current behavior
Every event in the kaapi-production Sentry project reports release 0.5.0. The release id comes from the hand-maintained API_VERSION setting, so it has not changed since April 2026. The release has no commits and no deploys attached, which means:
- "Regressed in release" and "Resolved in next release" do not work.
- Suspect commits are never shown on an issue.
- There is no way to tell from Sentry which production deploy introduced a problem.
Describe the enhancement you'd like
- Code (shared with staging): build the release id from Docker build args as
kaapi-backend@<RELEASE_TAG or API_VERSION>+<git sha 12>.SENTRY_RELEASEstays as an override.GIT_SHAalready exists in settings; addRELEASE_TAG. backend/Dockerfile: accept aRELEASE_TAGbuild arg..github/workflows/create-release.yml(tag push → ECS production):- checkout with
fetch-depth: 0 - resolve the same release id (
kaapi-backend@${GITHUB_REF_NAME}+${GITHUB_SHA::12}) - pass
--build-arg RELEASE_TAG=${{ github.ref_name }} - after both ECS rollouts succeed, register the release and deploy with
getsentry/action-release(environment: production,set_commits: auto)
- checkout with
- GitHub setup: Sentry organization token (
project:releases,org:read) as theSENTRY_AUTH_TOKENsecret, plusSENTRY_ORGandSENTRY_PROJECT(kaapi-production) variables. Without them the new step fails the deploy job.
Draft implementation and runbook: #1234 (docs/runbooks/sentry-release-tracking.md).
Why is this enhancement needed?
Faster triage after a production deploy: issues link to the commit and deploy that introduced them, and regressions are flagged automatically.
Additional context
- Staging is tracked separately; it deploys through a different workflow.
- Verify after the first tag deploy: Sentry → Releases shows the new id under
productionwith a non-zero commit count, and API and Celery report the same release.
- 主要语言
- Python
- 星标
- 18
- 派生
- 11
- 平均合并
- 3 天 11 小时
- 30 天内合并 PR
- 8
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ProjectTech4DevAI/kaapi-backend 的其他 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
ProjectTech4DevAI/kaapi-backend#889 ·
维护者通常 1 天内回复
-
Evaluation: Improve guardrails awareness可能已有人在做 @AkhileshNegi 于 15 天前认领。 未关闭enhancement
难度 5/5 一周以上 新手友好度 15/100
ProjectTech4DevAI/kaapi-backend#1246 ·
维护者通常 1 天内回复
-
Logging: Reduce INFO log noise可能已有人在做 @vprashrex 于 3 天前认领。 未关闭maintenance
ProjectTech4DevAI/kaapi-backend#1243 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Sentry Integration: Dynamic release tagging可能已有人在做 @vprashrex 于 3 天前认领。 未关闭enhancement parent
ProjectTech4DevAI/kaapi-backend#1242 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Sentry Integration: Track staging commits可能已有人在做 @vprashrex 于 3 天前认领。 未关闭enhancement
ProjectTech4DevAI/kaapi-backend#1241 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 ProjectTech4DevAI/kaapi-backend 的全部 Issue
相似的 Issue
-
Atomic append fails to create a missing file可能已有人在做 @harbinresearcher 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
fabiocaccamo/python-fsutil#201 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
task
难度 2/5 1-3 小时 新手友好度 78/100
danparshall/claude_researcher#87 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 62/100
GhostManager/Ghostwriter#998 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
datajoint/datajoint-python#1586 ·
维护者通常 1 天内回复