Skip to content

chore: drop the exclude entries for the retired mutation/fuzzing workflows #104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tschm merged 1 commit into from
Aug 22, 2026
Merged

chore: drop the exclude entries for the retired mutation/fuzzing workflows #104

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 0 additions & 31 deletions .rhiza/template.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,37 +21,6 @@ exclude:
# "Copyright (c) 2025 Jebel Quant Research", which is not this repo's holder.
- LICENSE

# The fuzzing workflow, which needs FUZZING_ENABLED plus a `.clusterfuzzlite/` config this repo
# does not have. Its gate sits *inside* the reusable workflow rather than in the caller, so it
# starts on every pull request and every push to main in order to skip -- a green check whose
# only content is that it had nothing to do.
- .github/workflows/rhiza_fuzzing.yml

# The mutation stub, for the same reason plus a worse one. This entry previously carried a note
# saying the caller was deliberately kept, because a MUTATION_ENABLED variable set to 'false'
# meant someone had configured the gate on purpose and flipping it to 'true' should be all it
# took. That premise was wrong: `gh api repos/Jebel-Quant/quadprog/actions/variables` returns
# `total_count: 0`, so the variable does not exist and never did.
#
# With nothing to flip, the stub's `if: vars.MUTATION_ENABLED == 'true'` can only skip -- and it
# triggers on `pull_request:`, so every PR starts a run in order to do so. Unlike the fuzzing
# caller the gate is at least in this file rather than inside the reusable workflow, but the
# visible result is identical: a green check whose only content is that it had nothing to do.
#
# It could not be turned on as it stands either. The reusable workflow fails the job if *any*
# mutant survives, and fourteen of this package's are provably equivalent, so a 100% gate can
# never go green here.
#
# Mutation testing is therefore not in CI in any form: the repo-owned weekly workflow that used
# to hold the middle ground -- scheduled rather than per-PR, gated on a baseline rather than on
# zero -- has been removed too, along with docs/development/MUTATION.md, which recorded the
# survivor baseline and which mutants are provably equivalent. Nor is there a working local
# route: rhiza-task's `mutation` task drives the mutmut 2.x CLI (jebel-quant/rhiza#1492), and the
# override that corrected that lived in the hand-written Makefile this repo replaced with the
# task-runner shim in v1.4. Recovering any of it starts with `git log --diff-filter=D` over the
# doc path above.
- .github/workflows/rhiza_mutation.yml

# The template's PAT_TOKEN and release-secret walkthrough. It documents secrets a consumer
# configures once in the platform UI, addressed to whoever set the repo up rather than to anyone
# reading the tree. Upstream is where it belongs, and where it stays.
Expand Down