Ujjwaljain16 opened a new pull request, #44248:
URL: https://github.com/apache/superset/pull/44248

   ### SUMMARY
   The weekly Docker base-image refresh (`scheduled-docker-image-refresh.yml`) 
fails for every currently published release with:
   
   ```
   ERROR: failed to build: failed to solve: target stage "superset" could not 
be found
   ```
   
   **Root cause:** #44100 added a `superset` Dockerfile stage and made it the 
preset backing the plain tags (`latest`, `<version>`, per-SHA), updating the 
current workflow matrices to match. The scheduled refresh, however, checks out 
the *release tag being refreshed* while its `supersetbot` tooling always comes 
from the *triggering* revision (deliberately, so release tags with stale Action 
pins don't break the job — see the existing comment on the "Checkout workflow 
actions" step). Every release cut before #44100 — 5.0.0, 6.0.0, 6.1.0, i.e. 
every currently published release — has no `superset` stage in its Dockerfile, 
so `--target superset` fails immediately.
   
   **Fix:** Before the real `--push` build, ask `supersetbot docker --dry-run` 
what target it would actually use, and check that stage against the Dockerfile 
just checked out for this release. If it's missing and the preset is `superset` 
and `lean` exists (the stage that produced the plain tags before #44100 split 
them out — see `docker-builds.mdx` as of that commit), build from `lean` 
instead, via `--extra-flags "--target lean --label target=lean"` (the last 
`--target`/`--label` wins on the assembled `buildx` command line, so the plain 
tag names/labels stay correct). Any other target/preset mismatch still fails 
the job loudly, same as today.
   
   The Dockerfile is intentionally untouched — it's an immutable snapshot of 
each release, and `lean` already existed there; there's nothing to fix in it. 
This is purely a case of workflow tooling assuming a newer Dockerfile shape 
than an older release actually has.
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   Not applicable (CI workflow change, no UI).
   
   ### TESTING INSTRUCTIONS
   - Reproduced the exact failure against the real 6.1.0 release commit 
(`c83fb2bb1dcfac41ac51bcebd82471f4a7180d18`) with `docker buildx build --target 
superset ...`.
   - Ran a full local `docker buildx build --load` using this fix's corrected 
logic against that same commit; it completed successfully, producing 
`apache/superset:6.1.0`, `:latest`, and per-SHA tags built from the `lean` 
stage, with the image's `target` label correctly reading `lean`.
   - Re-verified the fallback dynamically against `5.0.0`, `6.0.0`, `6.1.0`, 
and current `master` — no version hardcoding; current `master` (which has the 
`superset` stage) is a no-op, confirming future releases are unaffected.
   - Exercised all fallback branches directly (target exists / target missing 
with `lean` present / target missing without `lean` / non-`superset` preset) 
against the literal script extracted from the workflow file — each behaves as 
designed, including refusing to guess and failing the job loudly for any case 
outside the one verified compatibility gap.
   - `actionlint` and `shellcheck` clean on the changed step.
   - `tests/unit_tests/scheduled_docker_image_refresh_test.py`: 3 passed.
   
   To manually verify: trigger this workflow via `workflow_dispatch` (or wait 
for the next Monday cron) and confirm the `superset` matrix leg now succeeds 
against the current latest release instead of failing with the target-stage 
error.
   
   ### ADDITIONAL INFORMATION
   - [x] Has associated issue: Fixes #44220
   - [ ] 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
   - [ ] 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]

Reply via email to