CI: BReg tutorial job's retained-example recovery step runs zero tests
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
Research direction
Locate the workflow containing the Base Registry Engine tutorial from source job and inspect the Verify retained example recovery after process exit step. Run rg native_create_and_apply and the referenced cargo test command to identify whether a replacement test exists. Done means the step targets a real test or is removed, and zero-test filters cause the job to fail rather than pass.
Written by the indexing model from the issue text.
Description
The Verify retained example recovery after process exit step in the Base Registry Engine tutorial from source job runs:
cargo test --locked -p registry-bregctl --lib \
dev::examples::tests::native_create_and_apply_recover_after_process_exit_without_duplicate_revisions \
-- --ignored --exact
That test no longer exists anywhere in the tree (rg native_create_and_apply finds only the workflow). With --exact the filter matches nothing, so the step reports 0 passed; ... 415 filtered out and succeeds. This is true on main (for example run 36021883150, job 107709175818) as well as on PR branches.
The step therefore gives no assurance and costs one extra registry-bregctl lib test compile per run (about 13 s).
To decide: either point the step at the test that now covers "native create and apply recover after process exit without duplicate revisions", if one was renamed or moved, or delete the step. Either way, a step that names a single test should fail when the filter matches zero tests, for example by checking the running N tests count.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 5h 6m
- Merged PRs (30d)
- 170
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
agent-ready area:platform bug criticality:p3 rust triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
registrystack/registry-stack#1583 · 1 comment ·
Maintainers usually reply within 1 day
-
docs(breg): configure/breg.mdx lists stages for a request_lifecycle when, which bregctl refusesOpenagent-ready area:breg area:docs criticality:p3 documentation triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 92/100
registrystack/registry-stack#1574 ·
Maintainers usually reply within 1 day
-
area:docs area:release criticality:p2 documentation triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1474 ·
Maintainers usually reply within 1 day
-
agent-ready area:evidence bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
registrystack/registry-stack#1449 ·
Maintainers usually reply within 1 day
-
agent-ready bug criticality:p2 github_actions triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
Maintainers usually reply within 1 day
All issues in registrystack/registry-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
bytecodealliance/wasmtime#14433 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day