DanielLeens commented on PR #11836: URL: https://github.com/apache/seatunnel/pull/11836#issuecomment-5534467380
Good question, @nzw921rx — and the honest answer here is no, not in this specific case, which I think is worth flagging. This PR adds a new `pull_request:` trigger to `publish-e2e-spark-images.yaml` (which previously only had `workflow_dispatch:`). For security reasons, GitHub Actions resolves the `pull_request` event's workflow definition from the **base branch** (`dev`), not from the PR's head branch, when the workflow file itself is being changed by a fork PR. That means this new trigger will only start firing once this PR is merged into `dev` — it cannot validate itself within its own PR run. I checked the actual Actions history on @FenjuFu's fork and confirmed there's no `publish-e2e-spark-images` run at all for this head commit (`104998e16`), which lines up with that mechanism — the "Build" check that did pass here is the regular top-level `Build` workflow, unrelated to the new Spark image job. So the multi-arch build logic (`docker buildx bake` with `linux/amd64` + `linux/arm64` platforms, the new `SPARK_SHA512` checksum verification in the Dockerfile) is currently unverified by CI in this PR — it's only been exercised, if at all, by manual/local testing. I'd suggest either: 1. Merging with the understanding that the first real validation happens post-merge on `dev` (lower risk since this touches only test-image tooling, not production code), or 2. Asking @FenjuFu to trigger the workflow manually via `workflow_dispatch` on their fork against this branch to get one real CI signal before merge. Given this only affects E2E test infrastructure (not runtime code), I'd lean toward option 1, but wanted to make sure this gap is visible rather than silently assumed to be covered. Thanks for dismissing the earlier approval to raise this — it's a legitimate point. -- 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]
