Isolate Python 3.14 SDK snapshot publishes from the main matrix

[aIbrahiim]

Follow up to the Python 3.14 CI slowness work (#39401 / #39402): py314 multiarch snapshot builds are much slower and contend with other snapshot matrix jobs on the self-hosted pool

• Remove py314 / distroless:py314 from the main Snapshots matrix
• Add a separate job that runs after the main matrix (needs: + always() && !cancelled())
• Keeps py314 publishing, but stops it from starving faster snapshot publishes

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[github-actions]

Assigning reviewers:

R: @Abacn for label build.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[Abacn]

This change made some version specific logic which adds maintenance burden in the future. I see currently the workflow is green and work fine

========

I may have missed something, but currently the workflow already runs each python version in different matrix:

https://github.com/apache/beam/actions/runs/29992852197

as one can see, Python 3.14 and 3.14 distroless have they own job:

https://github.com/apache/beam/actions/runs/29992852197/job/89159380239

https://github.com/apache/beam/actions/runs/29992852197/job/89159380379

========

If the concern is on postcommit tests, we can make Python ARM PostCommits to use prebuild containers (gcr.io/apache-beam-testing/beam_python*_sdk:latest) to save time.

[aIbrahiim]

This change made some version specific logic which adds maintenance burden in the future. I see currently the workflow is green and work fine

========

I may have missed something, but currently the workflow already runs each python version in different matrix:

https://github.com/apache/beam/actions/runs/29992852197

as one can see, Python 3.14 and 3.14 distroless have they own job:

https://github.com/apache/beam/actions/runs/29992852197/job/89159380239

https://github.com/apache/beam/actions/runs/29992852197/job/89159380379

========

If the concern is on postcommit tests, we can make Python ARM PostCommits to use prebuild containers (gcr.io/apache-beam-testing/beam_python*_sdk:latest) to save time.

Thank you for the feedback @Abacn

okay right each Python version already has its own matrix job, I may have overstated that part and in this PR I was trying to only change when py314 runs so today everything starts together and shares the same runners, and this would make py314 wait until the main matrix finishes

But I got it as this adds version-specific logic and extra maintenance, and if Snapshots is already green, the benefit is pretty small

I will also consider reusing the prebuilt images and check in a new PR.

[aIbrahiim]

@Abacn
regarding py314 has its own matrix jobs, those jobs still start at the same timeas the others and share the same runners
and on the current pr I just tried to change the timing as main matrix runs without py314 first, then py314 / distroless:py314 run after (needs:) and it just tries to reduce runner contention
so yes the version-specific split adds maintenance if snapshots is already fine, maybe this isn't worth it