rusackas commented on code in PR #40426:
URL: https://github.com/apache/superset/pull/40426#discussion_r3315887254
##########
.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:
Valid finding — tag-release.yml had no concurrency block, so the two
workflows could race on apache/superset:latest and the versioned release tags.
Fixed in the latest commit: added the same `concurrency: { group:
docker-publish-latest-release, cancel-in-progress: false }` to tag-release.yml
so both Docker-publishing workflows participate in the same queue. Also updated
the comment in the new workflow to explicitly note that both files must declare
the group for the lock to be effective.
--
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]
