codeant-ai-for-open-source[bot] commented on code in PR #40426:
URL: https://github.com/apache/superset/pull/40426#discussion_r3301019356
##########
.github/workflows/scheduled-docker-image-refresh.yml:
##########
@@ -0,0 +1,127 @@
+name: Scheduled Docker image refresh
+
+# Re-runs the Docker image build against the latest published release on a
+# weekly cadence. The code being built doesn't change — but the base image
+# layers (python:*-slim-trixie and its OS packages) DO get upstream
+# security patches between Superset releases, and those patches don't
+# reach our published images unless we rebuild.
+#
+# Without this workflow, `apache/superset:<latest>` lags behind upstream
+# Debian/Python base patches by whatever interval falls between Superset
+# releases (typically 3–6 weeks). With it, the lag drops to at most one
+# week regardless of release cadence.
+#
+# This is a security-hygiene cron, not a release. It overwrites the
+# existing tags for the most recent release (e.g. `apache/superset:5.0.0`
+# and `apache/superset:latest`) with bit-for-bit-equivalent contents
+# layered on a refreshed base. Image digests change; everything users
+# actually pin against (image content, code, deps) does not.
+
+on:
+ schedule:
+ # Mondays at 06:00 UTC — gives the weekend for upstream patches to
+ # settle and surfaces failures at the start of the work week so a
+ # human can react.
+ - cron: "0 6 * * 1"
+
+ # Manual trigger so operators can force a refresh on demand (e.g.
+ # immediately after a high-severity base-image CVE drops).
+ workflow_dispatch: {}
+
+permissions:
+ contents: read
+
+# Serialize with itself AND with the release publisher — both push to the
+# same Docker Hub tags, so a race here could end with stale layers
+# winning.
+concurrency:
+ group: docker-publish-latest-release
+ cancel-in-progress: false
Review 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](https://app.codeant.ai/fix-in-ide?tool=cursor&prompt_id=4e4d5746b5f543d5924373db24b35ab1&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
| [Fix in VSCode
Claude](https://app.codeant.ai/fix-in-ide?tool=vscode-claude&prompt_id=4e4d5746b5f543d5924373db24b35ab1&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
*(Use Cmd/Ctrl + Click for best experience)*
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
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
```
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
