ci: schedule a weekly Docker image rebuild against the latest release#40426
Open
rusackas wants to merge 1 commit into
Open
ci: schedule a weekly Docker image rebuild against the latest release#40426rusackas wants to merge 1 commit into
rusackas wants to merge 1 commit into
Conversation
Adds a cron-triggered workflow that re-runs the Docker image build against the most-recent published release every Monday at 06:00 UTC (and on manual workflow_dispatch when an operator wants to force it). The Superset code being built doesn't change — but the base image layers (python:*-slim-trixie and the Debian OS packages underneath) DO receive upstream security patches between Superset releases. Without a rebuild, apache/superset:<latest> ships those CVEs unfixed for as long as the inter-release gap (typically 3–6 weeks). Why this approach over the alternatives: - Tied to releases: defeats the purpose — the gap we're trying to close IS the inter-release window. Release-triggered rebuilds happen exactly when we already get them. - Swap to Chainguard / distroless: would also close the gap, but at the cost of a backward-incompatible package-manager change for downstream operators who extend `apache/superset:<tag>` with their own apt install lines for custom drivers. A scheduled rebuild captures most of the CVE-cycling benefit without that breakage. - Daily cadence: probably overkill — Debian's security tree updates on a roughly weekly rhythm and a daily rebuild would just churn the registry without adding much. Implementation: deliberately reuses the same `supersetbot docker` invocation as `tag-release.yml` (same matrix of build presets, same `--context release --context-ref <tag> --force-latest` flags), so the resulting tags are byte-equivalent to what a manual release dispatch would produce — only the base layer changes. Concurrency group shared with the release publisher so the two can't race each other on the Docker Hub push. Tag mutability note: the rebuild overwrites both the rolling tags (`apache/superset:latest`) AND the version-specific tag of the latest release (e.g. `apache/superset:5.0.0`). This is intentional and matches how the upstream `python:*-slim-trixie` images themselves behave — version tags reflect content + latest patches, not a frozen SHA. Users who need a frozen reference should pin by image digest.
rusackas
requested review from
betodealmeida,
craig-rueda,
dpgaspar,
eschutho,
geido,
hainenber,
kgabryje,
mistercrunch,
nytai,
sadpandajoe and
villebro
as code owners
dosubot
Bot
added
github_actions
Contributor
|
Bito Automatic Review Skipped - Files Excluded |
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![codeant-ai-for-open-source[bot]](https://avatars.githubusercontent.com/u/151810221?s=60&v=4){kind=small}
Comment on lines
+37
to
+39
| concurrency: | ||
| group: docker-publish-latest-release | ||
| cancel-in-progress: false |
Contributor
There was a problem hiding this comment.
🟠 Architect Review — HIGH
The workflow comments assume Docker tag pushes are serialized with the release publisher, but only this new workflow defines concurrency.group: docker-publish-latest-release. .github/workflows/tag-release.yml has no concurrency block, so GitHub Actions will not coordinate the two workflows and they can still race on apache/superset:latest and versioned release tags.
Suggestion: Add the same concurrency group (docker-publish-latest-release) to .github/workflows/tag-release.yml (or centralize both callers through a reusable workflow that sets it) so both Docker-publishing workflows participate in the same lock and cannot race on the shared tags.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.
**Path:** .github/workflows/scheduled-docker-image-refresh.yml
**Line:** 37:39
**Comment:**
*HIGH: The workflow comments assume Docker tag pushes are serialized with the release publisher, but only this new workflow defines `concurrency.group: docker-publish-latest-release`. `.github/workflows/tag-release.yml` has no `concurrency` block, so GitHub Actions will not coordinate the two workflows and they can still race on `apache/superset:latest` and versioned release tags.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Contributor
|
The PR comment file contains only one comment row (line 2) with empty content. I cannot analyze or act on this data. Please ensure the PR comments file contains the necessary data for review. |
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
2 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.
SUMMARY
Adds a cron-triggered workflow that re-runs the Docker image build against the most-recent published release every Monday at 06:00 UTC (and on
workflow_dispatchwhen an operator wants to force it). The Superset code being built doesn't change — but the base image layers (python:*-slim-trixieand the Debian OS packages underneath) do receive upstream security patches between Superset releases. Without a rebuild,apache/superset:<latest>ships those CVEs unfixed for as long as the inter-release gap (typically 3–6 weeks).Why this approach over the alternatives
apache/superset:<tag>with their ownapt installlines for custom driversImplementation
Deliberately reuses the same
supersetbot dockerinvocation astag-release.yml:dev,lean,py310,websocket,dockerize,py311,py312)--context release --context-ref <tag> --force-latestflagsSo the resulting tags are byte-equivalent to what a manual release dispatch would produce — only the base layer changes. Concurrency group
docker-publish-latest-releaseis shared with the release publisher so the two can't race each other on the Docker Hub push.Tag mutability note
The rebuild overwrites both the rolling tags (
apache/superset:latest) and the version-specific tag of the latest release (e.g.apache/superset:5.0.0). This is intentional and matches how the upstreampython:*-slim-trixieimages themselves behave — version tags reflect content + latest patches, not a frozen SHA. Users who need a frozen reference should pin by image digest (apache/superset@sha256:...).BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A — CI configuration only.
TESTING INSTRUCTIONS
After merge:
Scheduled Docker image refresh→ "Run workflow") to confirm it picks up the latest release tag, builds all presets, and pushes successfully.docker run apache/superset:<tag> superset --help(and equivalents) should behave identically.ADDITIONAL INFORMATION