Skip to content

Stop release testing on Dependabot PRs and fix the release checklist - #264

Open
gomezzz wants to merge 2 commits into
developfrom
ci/release-checklist-and-dependabot
Open

Stop release testing on Dependabot PRs and fix the release checklist#264
gomezzz wants to merge 2 commits into
developfrom
ci/release-checklist-and-dependabot

Conversation

@gomezzz

@gomezzz gomezzz commented Aug 29, 2026

Copy link
Copy Markdown
Collaborator

Process defects found while shipping 0.6.0. No library code, no docs examples.

Revised after review. The first version of this PR filtered Dependabot with
a job-level if and regrouped concurrency by commit SHA. Neither would have
worked — see "What changed after review" at the bottom.

  • release_testing.yml drops its pull_request: branches: [main] trigger.
    That trigger ran the full three-backend × three-Python matrix a second time on
    every release commit, and also fired on Dependabot, which targets main
    because main is the default branch. Release branches already match the push
    trigger, and a push run reports as a check on the PR opened from that branch,
    so nothing is lost. A hotfix branch not named release-* now needs a manual
    dispatch — stated in both the checklist and the CI docs.
  • Concurrency goes back to grouping by github.ref. With one event type per
    branch that is correct again, and it recovers cancellation of runs superseded
    by a newer push.
  • Dependabot gets target-branch: "develop". This is the actual root cause.
    Targeting main violates the branching model (main takes releases, hotfixes
    and doc fixes only), and every merged action bump leaves main ahead of
    develop — which step 1 of the release checklist requires not to be the case.
    PR build(deps): bump the github-actions group with 4 updates #261 is an open example. Note Dependabot reads this file from the default
    branch, so the retarget only applies once it reaches main.
  • docs/source/ci_cd.rst still documented the pre-0.6.0 triggers. Now matches.
  • The release checklist gains three things 0.6.0 taught us. Closing keywords
    must be repeated before every issue number (Closes #1, #2, #3 closes only Added environment.yml #1,
    which left four issues open in 0.6.0); Read the Docs does not build tags unless
    a version is activated in its dashboard, which is why /en/vX.Y.Z/ has 404ed
    for every release including 0.5.0; and the conda-forge autotick bot bumps only
    version and sha256, so dependency changes — and the setuptools>=77.0.3
    the PEP 639 license expression needs — must be carried over by hand.

Related to #258.

Numerical behaviour

None — no library code is touched.

What changed after review

The review found that both original fixes were ineffective, and it was right:

  • A pull_request run uses the workflow file from the merge commit.
    Dependabot branches off main, so an actor filter merged to develop would
    not take effect until the next release carried it to main. My original test
    plan claimed the effect would be observable on merge; that was wrong.
  • cancel-in-progress only suppresses a duplicate while the first run is still
    running. The checklist verifies the push run is green before opening the PR,
    so by then there is nothing to cancel and the matrix runs twice regardless.
    Worse, when it did fire it would leave a cancelled release-tests check on the
    release PR, which checklist §4 does not account for.

Removing the trigger solves both, and makes the actor filter unnecessary.

Test plan

  • release_testing.yml parses as valid YAML: triggers are now
    push/workflow_dispatch/release, the concurrency group is back to
    github.ref, and the job-level if is gone.
  • .github/dependabot.yml parses with target-branch: develop.
  • sphinx-build -W -b html docs/source succeeds with the updated CI page.
  • Observable only after this reaches main: the next weekly Dependabot PR
    should open against develop and start no release-tests jobs.

The pull_request trigger carried the comment "only releases and hotfixes target
main". That is wrong: Dependabot targets the default branch, which is main, so a
GitHub Actions version bump ran the full three-backend, three-Python suite. A
job-level actor filter is the only place this can be expressed, since
pull_request cannot filter on who opened it.

The concurrency group was grouped by github.ref, which push and pull_request
report differently for the same commit, so it never deduplicated the pair it was
written to deduplicate -- the 0.6.0 release branch ran the matrix twice on every
commit. Grouping by the commit under test instead.

The release checklist gains three things learned shipping 0.6.0: closing keywords
must be repeated before every issue number or GitHub closes only the first, Read
the Docs does not build tags unless a version is activated in its dashboard, and
the conda-forge bot bumps only version and sha256, so dependency changes -- and
the setuptools floor the PEP 639 license expression needs -- must be carried over
by hand.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YP9oDLmw636HhPSAD6Nv3p
@github-actions

github-actions Bot commented Aug 29, 2026

Copy link
Copy Markdown

Overall Coverage

Coverage Report
FileStmtsMissCoverMissing
torchquad
   __init__.py26292%69–70
torchquad/integration
   base_integrator.py49786%28, 71–74, 78, 113, 117, 122
   boole.py30390%54, 73–76
   gaussian.py56395%97, 121, 143
   grid_integrator.py97397%50, 164, 268
   integration_grid.py49492%64–65, 132, 135
   monte_carlo.py93397%79, 101, 230
   qmc.py20195%67
   rng.py60788%71–74, 93–94, 102
   simpson.py29390%52, 71–74
   utils.py1311192%35–36, 102, 173, 177, 184, 196, 198, 204, 299, 306
   vegas.py167498%106–107, 212, 359
   vegas_map.py103892%247–257
   vegas_result.py25196%22
torchquad/utils
   deployment_test.py1926367%53–55, 65–66, 69–70, 78–79, 91–93, 164, 175–176, 180–181, 183–184, 196–199, 211–213, 221, 232–234, 237, 247, 250, 253, 256–259, 267–275, 280–288, 297–306, 316–323
   enable_cuda.py15660%17–22
   set_log_level.py18478%56–57, 72–73
   set_precision.py34974%35–38, 50–51, 70–72
TOTAL129014289% 

Tests Skipped Failures Errors Time
193 0 💤 0 ❌ 0 🔥 2m 35s ⏱️

…ng it

The previous attempt at this did not work, for two reasons the review caught.

A pull_request run uses the workflow file from the merge commit, and Dependabot
branches off main, so an actor filter living on develop would not have taken
effect until the next release shipped it to main. And the SHA-based concurrency
group only suppresses a duplicate while the first run is still in progress; the
release checklist verifies the push run is green *before* opening the PR, by
which point nothing is left to cancel, so the matrix ran twice anyway.

Dropping the pull_request trigger removes both problems at once, along with the
need for the actor filter. Release branches already match the push trigger, and a
push run reports as a check on the PR opened from that branch, so nothing is lost
except the duplicate. A hotfix branch not named release-* now needs a manual
dispatch, which the checklist and the CI docs both say.

Grouping by ref becomes correct again once only one event type reaches a branch,
so it goes back to cancelling superseded pushes.

Dependabot gets target-branch: develop. Targeting main violated the branching
model outright -- main takes releases, hotfixes and doc fixes only -- and every
merged action bump put main ahead of develop, which the first step of the release
checklist requires not to be the case.

docs/source/ci_cd.rst still described the pre-0.6.0 triggers; it now matches. The
closing-keyword item moves next to the bullet that opens the PRs, since that is
when the body is written.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YP9oDLmw636HhPSAD6Nv3p
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