Stop building and pushing container images outside a release
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 30/100
- Issue 類型
- 重構
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- docker, github-actions
研究方向
First resolve what image tag or digest relay.tnsor.network should deploy; the issue identifies this as a prerequisite. Read .github/workflows/checks.yml, .github/workflows/release.yml, and containers/nostream-dev-webhook/README.md, plus the relay deploy runbook. Done when main pushes publish no image, releases remain the only publisher, and the relay and deploy documentation no longer depend on unreleased :main.
由索引模型根據 Issue 內容生成。
描述
What happens
CI Checks (checks.yml) has a publish-container-image job that pushes ghcr.io/cameri/nostream on every push to main:
# .github/workflows/checks.yml:276
publish-container-image:
name: Build and push container image
if: >-
always() && github.event_name == 'push' && github.ref == 'refs/heads/main' &&
…
tags: |
type=raw,value=main
type=sha,prefix=sha-
Release (release.yml) pushes the same package on release: [published], which is the one time a published image should exist.
That was deliberate when it landed (#747, 14cca60, 2026-08-30): relay.tnsor.network deploys by pulling ghcr.io/cameri/nostream:main and recreating, so a merge needed a fresh image to deploy. The consequence is that the main tag is a moving pointer to unreleased main rather than a released artifact, and one docker pull ghcr.io/cameri/nostream can hand any consumer code that no release covers.
Requested change
Stop building and pushing outside a release. release.yml stays as the only publisher, and checks.yml builds without pushing (or stops building at all) if a PR-time image is worth keeping for smoke tests.
What has to move first
relay.tnsor.network pulls :main as its deploy mechanism — the server compose references POST /images/create?fromImage=ghcr.io/cameri/nostream&tag=main (containers/nostream-dev-webhook/.scratch/README.md) and the version-check row reads that digest. Removing the push without moving that consumer leaves the box unable to deploy; switching it needs a decision on what it tracks instead (latest release tag, a rolling edge tag built elsewhere, or a digest pinned per release).
Acceptance criteria
- A push to
mainthat publishes no release produces no new image inghcr.io/cameri/nostream. - Publishing a release still produces a tagged image, and
release.ymlis the only job withpackages: write. - Wherever
:mainis documented as a deploy target (containers/nostream-dev-webhook/README.md, the relay deploy runbook), the docs name the released tag instead. -
relay.tnsor.networkhas a deploy path that does not depend on an image built from unreleasedmain.
Evidence
- Run referenced in the request: actions/runs/39084587426, job
117548418140—CI Checks, push tomain, cancelled at 00:55:54Z while the publish job's prerequisites were still running. .github/workflows/checks.yml:276-334— the push,packages: write, and thetype=raw,value=maintag..github/workflows/release.yml:3-5—on: release: types: [published], the intended trigger.
- 主要語言
- TypeScript
- 星號
- 829
- 分支
- 234
- 平均合併
- 18 小時 43 分鐘
- 30 天內合併 PR
- 67
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
cameri/nostream 的其他 Issue
-
Website
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
-
documentation Website
難度 4/5 3-5 天 新手友好度 52/100
維護者通常 1 天內回覆
-
fix(website): update operator console film with fresh notifications screenshot可能已有人在做 @Ferryx349 今天認領。 未關閉bug Website
cameri/nostream#893 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
Koenkk/zigbee-herdsman-converters#13540 ·
維護者通常 1 天內回覆
-
check:passed streams:add
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
area/busola/ux
難度 2/5 1-3 小時 新手友好度 68/100
kyma-project/busola#5442 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
vercel-labs/wterm#246 ·
維護者通常 1 天內回覆