Restore GitHub Actions CI

[aaronspring]

Description

CI on this repository has not run at all since 2026-09-06, and the weekly run was partly inert for a long time before that. This PR is limited to getting it working again.

1. Both workflows were disabled. GitHub had set them to disabled_inactivity, which it does to scheduled workflows after 60 days without a commit (last commit to main was 2026-07-07). That state belongs to the workflow record, which GitHub keys to the file's path — so pushing commits does not clear it, and workflow_dispatch is refused outright. Registering the files at new paths creates fresh workflow records, which start active:

testing.yml         -> ci.yml
upstream-dev-ci.yml -> upstream-dev.yml

Job names, workflow name: values and triggers are unchanged, so branch-protection rules that key off check-run names keep matching. Confirmed working: Upstream Test run #1 under a new workflow id fired on the push that did the rename.

2. The weekly CI never actually ran the tests. detect-ci-trigger is gated on push/pull_request, so on schedule and workflow_dispatch it is skipped — taking the three test-matrix jobs that needs: it down with it. Run 144 (2026-09-06) shows all three as "conclusion": "skipped"; the weekly run had quietly degraded to just the doctest and notebook jobs. Now gated on always() plus an explicit triggered != 'true'.

3. Upstream Test died before running a single test, pinned to Python 3.10 while upstream xclim requires >=3.11:

ERROR: Package 'xclim' requires a different Python: 3.10.21 not in '>=3.11.0'

4. Upstream failure reporting was broken — it used ::set-output, which GitHub removed, so ARTIFACTS_AVAILABLE was never set and the report job never opened its failure issue. Now $GITHUB_OUTPUT. This is plausibly why the weekly failures went unnoticed for so long.

Also fixes the CI badge in README.rst and docs/source/index.rst (it pointed at climpred_testing.yml, a path removed in an earlier rename, so it rendered nothing), and drops a dangling always-true and "lead" clause in _rps that fails the ty pre-commit hook on main.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Actions is demonstrably alive again: the rename produced a new workflow record and a run on this PR.

• Fixes 3 and 4 are confirmed by that run's log — the environment built and pytest ran (instead of failing at install), and the log shows Set output 'artifacts_availability'.

• pre-commit run --all-files passes, including the workflow-schema hook and ty.

• Tests added for pytest, if necessary. — not applicable; this is CI configuration.

Checklist (while developing)

• CHANGELOG is updated with reference to this PR.

Known red checks, both pre-existing on main

• doctest — the HindcastEnsemble.remove_bias doctest for how="modified_quantile" pins stale values that no longer match current bias_correction output. Reproduces on main; deliberately left for its own PR so this one stays on a single subject.
• upstream-dev — segfaults in netCDF4's C extension while opening a tutorial dataset in fixture setup (conftest.py:413 → load_dataset → xr.open_dataset). This is the signature of a numpy ABI mismatch: ci/install-upstream-wheels.sh pip-installs nightly numpy/pandas with --no-deps over a conda env whose netCDF4, bottleneck, numba and sklearn were compiled against the conda numpy. It needs its own fix in that script. Note this job is a nightly canary against bleeding-edge upstream mains, not a merge gate — it only runs here because of a [test-upstream] keyword used to validate the Python bump.

🤖 Generated with Claude Code

https://claude.ai/code/session_012xXJVZrXR4k3BmmDeTLEaD

[aaronspring]

upstream-dev segfault — not this PR's defect, needs its own fix

Recording this since it surfaced here and should not be lost.

What fails. upstream-dev crashes hard while opening a tutorial dataset during fixture setup:

netCDF4._netCDF4                                    ← last extension module loaded
xarray/backends/netCDF4_.py:563 in ds
xarray/backends/api.py:619 in open_dataset
src/climpred/tutorial.py:223 in load_dataset
src/climpred/conftest.py:413 in hindcast_NMME_Nino34
Segmentation fault (core dumped)

It is not caused by the Python version bump in this PR. I ran 3.12 alongside 3.13 once to check, and both segfault:

Python	Result	Crash point
3.13	failed ×2	test_remove_bias_unfair_artificial_skill_over_fair[basic_quantile-season-same_verifs]
3.12	failed ×2	test_remove_bias_unfair_artificial_skill_over_fair[additive_mean-month-maximize]

The crash point moves between interpreter versions, which points at memory corruption rather than a logic bug.

Likely cause. ci/install-upstream-wheels.sh pip-installs nightly numpy/pandas with --no-deps --upgrade on top of a conda environment whose netCDF4, bottleneck, numba and sklearn were compiled against the conda numpy. That is the classic setup for an ABI mismatch, and numpy.ndarray size changed, may indicate binary incompatibility shows up in these environments as the usual precursor. Fixing it properly means reworking how that script layers nightly wheels over conda-built extensions — a separate change from restoring CI, so I have not bundled it here.

Why this PR no longer runs the job. upstream-dev is a nightly canary against bleeding-edge upstream mains, not a merge gate. It only ran on this PR because I added a [test-upstream] keyword to verify that the Python bump fixed the install-time failure. It did — the environment now builds, import climpred succeeds, and the suite runs for several minutes instead of dying in Set up conda environment within 40 seconds. That verification is done, so later commits drop the keyword. The job remains fully enabled on its weekly schedule and on any PR that opts in; nothing is skipped, disabled or quarantined.

One incidental confirmation from the same runs: the ::set-output → $GITHUB_OUTPUT fix works — the logs now show Set output 'artifacts_availability', so the report job will once again open/update the upstream-failure issue. That reporting path had been silently broken, which is plausibly why these weekly failures went unnoticed for so long.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.27%. Comparing base (9368dca) to head (6452311).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #929   +/-   ##
=======================================
  Coverage   91.27%   91.27%           
=======================================
  Files          59       59           
  Lines        6548     6548           
=======================================
  Hits         5977     5977           
  Misses        571      571           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aaronspring]

Correction: the stale nightly index was not the cause of the upstream-dev segfault

Correcting my comment above, which pointed at ci/install-upstream-wheels.sh resolving numpy/pandas from the unmaintained scipy-wheels-nightly index. That inconsistency is real — matplotlib two lines below already used scientific-python-nightly-wheels — and the switch is worth keeping on its own terms, but it does not fix the segfault.

With the index switched (6452311):

	before (5b8a213)	after (6452311)
Set up conda environment	success	success, 64s
Run Tests	failed after 5m46s / 7m04s	failed after 9m49s
crash point	…[basic_quantile-season-same_verifs] (3.13), …[additive_mean-month-maximize] (3.12)	…[modified_quantile-season-same_verifs]
pandas C extension	pandas._libs.json	pandas._libs._ujson

So the change did take effect — a different pandas build was installed and the suite ran ~3 minutes further — but it still ends in Segmentation fault (core dumped), always inside test_remove_bias_unfair_artificial_skill_over_fair, with netCDF4._netCDF4 loaded.

What this points to instead. The crash point moves whenever the installed numpy/pandas change, which is the signature of memory corruption rather than a defect in any one package. The likely root cause is structural: the script force-uninstalls numpy/pandas and reinstalls nightlies with --no-deps, while leaving conda-built extensions (netCDF4, bottleneck, numba, sklearn, pyarrow, scipy) that were compiled against the numpy the environment was originally solved with. Whichever numpy the nightly resolves to is a different C-API build than those extensions expect.

If that is right, the fix is not a URL but a restructuring — either also reinstall the compiled extensions from pip so they build against the nightly numpy, or stop force-uninstalling numpy and let the nightlies come in as a consistent set. That needs iterating in CI against the real environment, so it belongs in its own PR.

Worth restating: upstream-dev is a weekly canary against bleeding-edge upstream mains, not a merge gate, and nothing about it is skipped, disabled or quarantined.

---

Generated by Claude Code