Skip to content

ci: drop redundant release test run + patch bart26g Dependabot vulns#84

Merged
bartzbeielstein merged 4 commits into
mainfrom
fix/ci-redundancy-and-paper-vulns
Jun 2, 2026
Merged

ci: drop redundant release test run + patch bart26g Dependabot vulns#84
bartzbeielstein merged 4 commits into
mainfrom
fix/ci-redundancy-and-paper-vulns

Conversation

@bartzbeielstein
Copy link
Copy Markdown
Contributor

Context

Follow-up to #83. Two issues surfaced right after that merge:

  1. Redundant test runs. Merging a PR to main triggered the Release workflow, which re-ran the fast test suite that the PR's CI check had just run. Two parallel runs testing the same code on the same commit — wasted minutes on the publish path with no added signal.
  2. 18 open Dependabot alerts on the default branch (11 high, 7 moderate).

1. Reduce CI/Release redundancy (release.yml)

Why it's safe to remove: tests are already gated on every PR by ci.yml (the required fast check) and run in full nightly. The Release pipeline only runs on push to main, i.e. after a PR merged green — so re-testing the merge commit duplicated work. release.yml now publishes and deploys docs without re-testing.

Assumption: main is updated only via PRs (so the required CI check always runs first). If direct pushes to main are expected, keep branch protection's required Tests (fast) check enabled.

2. Patch Dependabot vulnerabilities (bart26g/uv.lock)

All 18 alerts were in the bart26g/ paper subproject lockfile (a Quarto/arXiv manuscript with its own jupyter-based deps) — none in the shipped spotoptim package. Bumped the vulnerable transitive deps to patched versions:

package before after fixes
idna 3.11 3.17 ≥3.15
mistune 3.2.0 3.2.1 ≥3.2.1
urllib3 2.6.3 2.7.0 ≥2.7.0 (2 high)
jupyterlab 4.5.6 4.5.7 ≥4.5.7
notebook 7.5.5 7.5.6 ≥7.5.6
jupyter-server 2.17.0 2.19.0 ≥2.18.0

Dependabot re-scans bart26g/uv.lock once this lands on main and should close all 18 alerts. Also restamps the main uv.lock spotoptim version 0.12.1 → 0.12.4 to match pyproject.toml (the lock had drifted after the semantic-release bump).

Note: these are build/authoring deps for a paper, not runtime deps of the toolbox. If you'd rather Dependabot not track the paper subproject at all, a follow-up could add a scoped .github/dependabot.yml — say the word.

Commit types

ci: and chore(deps): — neither triggers a semantic-release version bump.

🤖 Generated with Claude Code

bartzbeielstein and others added 4 commits June 2, 2026 02:09
Tests are already gated on PRs by ci.yml (required fast check) and nightly (full suite). Re-running the fast suite on the merge-to-main push duplicated cost without adding signal, so the release workflow now publishes and deploys docs without re-testing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
All 18 open Dependabot alerts were in the bart26g/ paper subproject lockfile (none in the shipped spotoptim package). Bump vulnerable transitive deps to patched versions: idna 3.11->3.17, mistune 3.2.0->3.2.1, urllib3 2.6.3->2.7.0, jupyterlab 4.5.6->4.5.7, notebook 7.5.5->7.5.6, jupyter-server 2.17.0->2.19.0. Also restamps the main uv.lock spotoptim version (0.12.1->0.12.4) to match pyproject.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
objective_remote() called requests.post() with no timeout. When the remote server is unreachable and packets are dropped (as on GitHub runners, vs an immediate connection-refused locally) the socket hangs indefinitely — the fast test suite ran 20+ minutes instead of ~1 and had to be cancelled.

Add a default (connect, read) timeout of (10, 120)s, exposed as a `timeout` parameter. Defense in depth: set pytest-timeout's global timeout=300 so no single test can hang the suite, and mark the networked test_objective_remote as slow so the fast PR gate skips it (the nightly full run still exercises it, now bounded by the timeout).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The fast suite took ~52 min on CI while running ~48s locally. Cause: pytest-xdist (-n auto) starts one worker per core, and each worker's numpy/scipy/torch BLAS pool also spawned threads-per-core, so tiny linear-algebra tests thrashed (67-83s for tests that are <1s locally — a ~65x systemic slowdown).

Pin OMP/OPENBLAS/MKL/NUMEXPR/VECLIB thread pools to 1: as a top-level env block in ci.yml (guaranteed before any process starts) and via os.environ.setdefault at the top of tests/conftest.py (so local runs and the pre-push hook benefit too, before numpy is imported). This does not affect SpotOptim's own n_jobs/thread-pool parallelism, only native BLAS threads.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@bartzbeielstein bartzbeielstein merged commit 3dc03ed into main Jun 2, 2026
5 checks passed
@bartzbeielstein bartzbeielstein deleted the fix/ci-redundancy-and-paper-vulns branch June 4, 2026 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant