aglinxinyuan opened a new pull request, #7721:
URL: https://github.com/apache/texera/pull/7721
### What changes were proposed in this PR?
`renovate.json5` already freezes `numpy` / `pandas` / `pyarrow` as Arrow IPC
data-path pins, but not the **interpreter** their wheels are selected for.
Renovate raised `actions/setup-python`'s `python-version:` to 3.14 in #7715,
and `build / amber-integration` failed on both runners at *Install Python
dependencies*:
```
Before: Renovate bumps python-version -> 3.14 -> no numpy cp314 wheel
-> uv source-builds numpy -> 11 compile errors -> job fails
After: python-version frozen with the numpy/pandas pins
-> prebuilt wheel resolves -> job installs as before
```
The interpreter is downstream of the pins the rule above deliberately holds
back:
| Pin in `amber/requirements.txt` | Wheels published | cp314? |
| --- | --- | --- |
| `numpy==2.1.0` | cp310–cp313 | no |
| `pandas==2.2.3` | cp310–cp313 | no |
| `pyarrow==23.0.1` | cp310–cp314 | yes |
So this adds one `packageRules` entry disabling the `python` dep under the
`github-actions` manager, directly below the pins it is coupled to, with a
comment recording why. Both `python` and `actions/python-versions` are listed
because Renovate names the dep `python` while resolving it from that releases
repo.
Freezing rather than capping at `<3.14` was deliberate: matching is by name,
so the rule can be verified offline, whereas an `allowedVersions` range is
compared against `actions/python-versions` strings like `3.14.7-31064857500`
and a wrong range fails silently in either direction.
Three sites stop moving on their own — `build.yml:401` (`amber-integration`,
3.11), `build.yml:127` (`frontend`, 3.12), `benchmarks.yml:217` (`Bench`,
3.12). The pyamber matrix at `build.yml:1041` is `["3.11", "3.12", "3.13"]`, a
plain list Renovate never read, so it has to be widened in the same manual step
as the pins — the comment says so.
Not addressed here: `build / frontend (macos-latest)` is also red on #7715,
but that reproduces on clean `main` and is the Vitest CI stall already tracked
by #7623 (details below).
### Any related issues, documentation, discussions?
Closes #7720
### How was this PR tested?
Validated with Renovate's own validator, in repo-config mode
(auto-discovery, run from the repo root):
```bash
npx --yes --package renovate renovate-config-validator
```
```
INFO: Validating .github/renovate.json5
INFO: Config validated successfully against 1 file(s)
```
Negative control, to confirm the validator actually inspects `packageRules`
rather than rubber-stamping the file — temporarily renaming the matcher and
adding a junk key:
```
ERROR: Found errors in configuration
"errors": [
{ "message": "Invalid configuration option:
packageRules[19].bogusOption" },
{ "message": "Invalid configuration option:
packageRules[19].matchDepNamesTYPO" }
]
```
Wheel availability confirmed against PyPI, which is the fact the rule
encodes:
```bash
curl -s https://pypi.org/pypi/numpy/2.1.0/json | grep -o 'cp3[0-9][0-9]' |
sort -u # cp310 cp311 cp312 cp313
curl -s https://pypi.org/pypi/pandas/2.2.3/json | grep -o 'cp3[0-9][0-9]' |
sort -u # cp310 cp311 cp312 cp313
```
Matching the failing CI log from #7715, which source-builds numpy for cp314
and stops on the 3.14 headers:
```
Building numpy==2.1.0
× Failed to build `numpy==2.1.0`
╰─▶ Call to `mesonpy.build_wheel` failed (exit status: 1)
../numpy/_core/src/umath/string_fastsearch.h:132:5: error: no type
named
'ptrdiff_t' in namespace 'std'
11 errors generated.
numpy/_core/_multiarray_umath.cpython-314-darwin.so.p/...
```
Separately, `build / frontend (macos-latest)` was checked and ruled out as
unrelated: it fails the same way on a **push to `main`** at `7a2c8d03b5`, which
carries none of #7715's changes — same step, same `Test timed out in 5000ms`,
~332s run, a different randomly-hit spec each time. That is #7623, not this.
The rule itself only takes effect once Renovate next regenerates the
`github-actions` branch, so #7715 needs a rebase after this merges to pick it
up.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (claude-opus-5)
--
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]
