Ujjwaljain16 commented on PR #44248: URL: https://github.com/apache/superset/pull/44248#issuecomment-5783858530
@rusackas this needed more than a rebase, so wanted to explain before you see the diff jump around [apache/superset#44250]( https://github.com/apache/superset/pull/44250) (merged 2026-09-21) removed scheduled-docker-image-refresh.yml entirely deliberately as a matter of release-publishing policy, not because of anything in this PR per its description : "the scheduled release refresh workflow is removed, so official release tag digests are not overwritten outside release publishing" that's why GitHub showed a conflict: the file this PR patches doesn't exist on master anymore but the underlying #44220 hazard didn't go away it moved the redesigned tag -release.yml (now the sole path for official image publishing) checks out an arbitrary historical release ref mid-job via workflow_dispatch or a release: edited event while keeping supersetbot from the triggering (current master) revision [apache/superset#44250](https://github.com/apache/superset/pull/44250) even added a "Preserve Docker flags helper" step to keep docker-build-extra-flags.sh available across that checkout, for PY_VER/cache concerns but nothing analogous for --target so editing an old GitHub Release, or manually re-dispatching against an old tag, with BUILD_PRESET=superset still reproduces #44220's exact failure i don't think this was a deliberate call in [apache/superset#44250](https://github.com/apache/superset/pull/44250) it doesn't reference #44220 or this PR anywhere, and its whole focus was tag-staleness/concurrency/cache scripts/docker_release_target.py and its 12 tests needed no changes the fix logic was always correct i retargeted this PR: dropped the (now-deleted) workflow changes, and wired the same helper into tag-release.yml's docker-release job using the exact pattern already established there for docker-build-extra-flags.sh (preserve a copy from master before the release-ref checkout, since the release's own tree won't have it either) validated with the real supersetbot CLI against three scenarios, using the actual preserved-helper-path structure the workflow uses (script invoked from a path other than the release checkout, matching production): Historical release (6.1.0) + preset=superset → correctly falls back to --target lean --label target=lean. Current-Dockerfile release + preset=superset (the normal/common path for a brand-new release) → exact no-op, confirmed unaffected. Historical release + preset=lean (already-working case) → unaffected. also rewrote this branch's history against current master (force-pushed) rather than merging the earlier merge-from-master commit on here predates [apache/superset#44250](https://github.com/apache/superset/pull/44250) and is now moot -- 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]
