villebro opened a new pull request, #44545:
URL: https://github.com/apache/superset/pull/44545
### SUMMARY
Release branches publish nothing to Docker Hub today:
`scripts/docker-build-plan.sh` sets `--push` only for `refs/heads/master`, and
official release images come from `tag-release.yml`, which fires on a GitHub
release — i.e. after the vote. That leaves a release manager with no container
image of the current state of a release branch to smoke-test before an RC is
cut.
Pushes to a branch named exactly `N.N` now publish commit-addressable
pre-release images — `apache/superset:<branch>-<short-sha>`, plus the `-lean`
and `-dev` variants — multi-arch, matching official release images:
```bash
docker pull apache/superset:7.0-a1b2c3d
```
No mutable tag is moved, so a cherry-pick that lands late can never
overwrite a newer image, and `docker-publish-guard.sh` stays master-only for
that same reason. Official release tags (`X.Y.Z`, `latest`, preset variants)
remain published solely by the release workflow after sign-off.
Design notes:
- **Classification lives in the plan script, not in YAML.** GitHub `if:`
expressions have no regex, and this workflow's push filter (`"[0-9].[0-9]*"`)
is looser than `N.N` — it also matches branches like `0.36.0-lyft1` and
`2021.21.1`. The script matches `^refs/heads/([0-9]+\.[0-9]+)$` and derives the
tag from that capture, so only digits and a dot can reach a published tag.
Downstream steps key off a `pushed` output rather than re-deriving the rule,
which also removes a third copy of the master ref check.
- **Forks are gated.** The Docker Hub login step is `continue-on-error`, so
without a `GITHUB_REPOSITORY` check a fork pushing an `N.N` branch would spend
a full build and then fail on a registry 401.
- **Only three presets publish** (`superset`, `lean`, `dev`). Everything
else on a release branch still builds as `--load` validation.
- **`master` keeps sole ownership of the shared `apache/superset-cache`
ref.** Release branches read those layers, never export to them.
- **The `Docker pull` step is now load-bearing on release branches** — a
`--push` build leaves nothing in the local daemon, so the WebSocket smoke test
would otherwise have no image to run. Grype follows the same "scan whatever we
publish" rule; code scanning scopes analyses per ref, so branch findings don't
overwrite master's.
This partially revises the policy added in #44250. The rationale there still
holds where it was aimed: PR images stay unpublished because the code is
untrusted. A protected, committer-only release branch is a different risk
profile.
Because GitHub runs a push workflow from the pushed branch, this takes
effect on a release branch only once cherry-picked into it.
### TESTING INSTRUCTIONS
The always-on `docker-command-check` job asserts the behaviour against the
real assembled `buildx` command line, including the new `7.0-<sha7>` tag per
preset and the negative cases (non-`N.N` branch, release-looking tag name,
fork, validation-only preset).
Verified locally by installing `supersetbot`, extracting that job's script
from the workflow, and running it end to end. Mutation-tested: removing the
fork gate, loosening the branch regex, or widening the preset allowlist each
produce a failing assertion.
```bash
pytest tests/unit_tests/scripts/docker_build_plan_test.py
bash scripts/docker-build-plan.sh push refs/heads/7.0 7.0 superset \
0123456789abcdef0123456789abcdef01234567 apache/superset
# -> PUSH_OR_LOAD=--push, multi-arch, RELEASE_BRANCH_TAG=7.0-0123456
bash scripts/docker-build-plan.sh push refs/heads/0.36.0-lyft1 0.36.0-lyft1
superset \
0123456789abcdef0123456789abcdef01234567 apache/superset
# -> PUSH_OR_LOAD=--load, RELEASE_BRANCH_TAG=''
```
End-to-end confirmation is the first push to `7.0` after this is
cherry-picked there; the run prints a `::notice::` with the exact published tag.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [x] Introduces new feature or API
- [ ] Removes existing feature or API
--
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]