Skip to content

[Fix][CI] Pin the Python SDK workflow to ubuntu-24.04 so Python 3.9 can be installed - #12994

Merged
nzw921rx merged 1 commit into
apache:devfrom
karthik-0306:fix/python-sdk-ci-ubuntu-24.04
Oct 28, 2026
Merged

nzw921rx merged 1 commit into
apache:devfrom
karthik-0306:fix/python-sdk-ci-ubuntu-24.04

Conversation

@karthik-0306

Copy link
Copy Markdown
Contributor

Purpose of this pull request

Follow-up to #12857, related to #12707. This PR contributes a CI fix to Apache SeaTunnel.

ubuntu-latest now points to Ubuntu 26.04, and actions/setup-python has no Python 3.9 build for it, so the Test with Python 3.9 job in .github/workflows/python-sdk.yml fails at "Set up Python" for every SDK pull request ("The version '3.9' with architecture 'x64' was not found for Ubuntu 26.04", seen on #12858). In the actions/python-versions manifest, 3.9.25 has Linux x64 builds for Ubuntu 22.04 and 24.04 only, while 3.10 and 3.13 also have 26.04 builds.

This pins the job to ubuntu-24.04, which has both 3.9 and 3.13. 3.9 is still the python_requires floor in tools/seatunnel-python-sdk/setup.py, so dropping it from the matrix would stop testing the declared minimum.

If you'd rather raise the SDK's minimum Python to 3.10 instead of pinning the runner, I'm happy to change this PR to that; I kept 3.9 because it is still the declared python_requires floor.

Does this PR introduce any user-facing change?

No. CI only.

How was this patch tested?

  • Checked the actions/python-versions manifest: Python 3.9 is available for ubuntu-24.04.
  • Validated the YAML locally (runs-on: ubuntu-24.04, matrix unchanged: 3.9 and 3.13).
  • The SDK suite passes locally on Linux with Python 3.9, 3.10 and 3.13.
  • This PR changes the workflow file, so the workflow runs on this PR itself once a maintainer approves the run.

Check list

@DanielLeens DanielLeens left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the quick follow-up on #12857, @karthik-0306. This is a small, well-explained CI fix, and it is easy to review.

What Problem Does This PR Solve?

  • User pain point: The Test with Python 3.9 job in python-sdk.yml fails at "Set up Python" for every SDK PR. The PR reports that ubuntu-latest now resolves to Ubuntu 26.04 and actions/setup-python has no 3.9 build for it (error seen on #12858).
  • Fix approach: Pin the job to runs-on: ubuntu-24.04 and keep the matrix (3.9, 3.13) unchanged, with an explanatory comment.
  • One-sentence summary: Pin the Python SDK workflow runner to Ubuntu 24.04 so the declared minimum Python (3.9) can still be installed and tested.

1. Code Change Review

1.1 Core Logic Analysis

The diff is one line in .github/workflows/python-sdk.yml:

# before
runs-on: ubuntu-latest
# after
# Pinned: actions/setup-python has no Python 3.9 build for Ubuntu 26.04, which
# ubuntu-latest now points to, and 3.9 is still the python_requires floor.
runs-on: ubuntu-24.04

Findings:

  • tools/seatunnel-python-sdk/setup.py:26 declares python_requires='>=3.9', and the matrix tests exactly the floor (3.9) and a current release (3.13). Keeping 3.9 under test is the right call. Dropping it would silently stop testing the declared minimum.
  • The pin is the smallest change that restores the job. The workflow has no other ubuntu-latest use, so nothing else in this file needs the same treatment.
  • ubuntu-24.04 is already used by other workflows in this repo (benchmarks.yml:68, benchmarks_diagnostics.yml:72), so there is precedent and no new runner type is introduced.
  • The change only affects the CI runner image. The trigger paths, permissions, concurrency group and steps are untouched, and no engine, API, serialization or checkpoint path is involved.
  • I could not independently re-verify the claim that ubuntu-latest currently maps to 26.04 or the contents of the actions/python-versions manifest from this review. The PR description gives the exact error text from #12858, which is consistent with the claim. The PR's own CI run will confirm it in practice.

1.2 Compatibility Impact

Fully compatible. This is CI-only. There is no change to runtime code, configuration options, public APIs, data formats or user-facing behavior, and no incompatible-changes.md update is needed.

1.3 Performance / Side Effects

No production performance impact. ubuntu-24.04 is a stable, widely available runner label. The only side effect is that the job will no longer follow ubuntu-latest automatically (see the non-blocking note below).

1.4 Error Handling and Logging

No formal issues. The failure mode this PR removes (job failing at the setup step) is exactly what it targets.

Informational (not counted as an issue): pinning means the runner will eventually age out and someone will need to bump it. The added comment explains the reason well, which makes that follow-up easy.

2. Code Quality

2.1 Coding Standards

The comment above runs-on explains why (why) rather than restating the code. No Java code changed, so the license header and Javadoc rules do not apply. Title follows the [Fix][CI] convention.

2.2 Test Coverage and Test Stability

No tests were added or changed; the workflow itself is the verification. Stability rating: Stable. The change removes a deterministic setup failure and does not introduce timing or environment dependence. Note that no CI checks were reported yet at review time (the PR touches a workflow file, so a maintainer needs to approve the workflow run). I have not claimed any runtime validation. The first run of Test with Python 3.9 and Test with Python 3.13 on this PR is the real proof, and I would like to see both green before merge.

2.3 Documentation

No user-visible change, so docs/en and docs/zh need no update.

3. Architectural Soundness

3.1 Fix Quality

Precise fix. It targets the exact cause (no 3.9 build for the newer runner image) without changing the tested Python range.

3.2 Maintainability

Good. A one-line change with an explanatory comment, consistent with other workflows that already pin ubuntu-24.04.

3.3 Extensibility

Fine for now. When the SDK raises its floor to 3.10 or later, the pin can be removed and ubuntu-latest restored. A short TODO-style note is optional and not required.

3.4 Historical-Version Compatibility

Not affected. Only the CI runner for a tooling SDK changes. Release branches that carry this workflow keep their own copy.

4. Issue Summary

Number Issue Location Severity
- No formal issues found - -

5. Merge Recommendation

Conclusion: Ready to merge

Blockers: none.

Non-blocking suggestions:

  • Please let the workflow run on this PR finish and confirm both matrix jobs (Python 3.9 and 3.13) pass before merging. They were not yet reported when I reviewed, so I am leaving this as a comment rather than an approval.
  • Optionally, link the follow-up that will remove the pin once the SDK floor moves to 3.10 or later.

Overall assessment: A focused, low-risk CI fix that restores the Python 3.9 job without weakening test coverage. Nice work, and thank you for also offering the alternative of raising the minimum Python version; keeping the declared floor under test is the more conservative choice, and I agree with it.

Alternatives considered: (a) Raise python_requires to 3.10 and drop 3.9 from the matrix: it changes the SDK's public support contract and is out of scope for a CI fix. (b) Use a container/deadsnakes workaround: more moving parts than a runner pin. The pin is the best option here.

@github-actions github-actions Bot added the CI&CD label Oct 28, 2026

@nzw921rx nzw921rx left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 good job

@nzw921rx
nzw921rx added this pull request to the merge queue Oct 28, 2026
Merged via the queue into apache:dev with commit c8e7896 Oct 28, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants