CI on `main` drops queued runs, so some merged commits never get their own CI run
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 67/100
Research direction
Start by reading .github/workflows/ci.yml and .github/workflows/commit-policy.yml, especially their concurrency groups and the documented promise that each push to main is checked. Decide whether to adjust concurrency or soften that promise, then inspect the workflow runs for closely spaced merges to confirm the behavior. Done means the workflows and documentation agree, and the stated behavior for successive main commits is verified.
Written by the indexing model from the issue text.
Description
What happens. ci.yml's concurrency group is ci-${{ github.workflow }}-${{ github.ref }}, with cancel-in-progress false on main. GitHub still cancels a pending run in the same group when a newer one queues. Recent main push runs that were cancelled before any job ran (0 jobs):
| run | commit | queued |
|---|---|---|
| 40486165734 | bc92022 (#615) | 2026-10-27 |
| 37547961147 | 6e7d7c4 | 2026-10-06 |
| 36289366035 | 305bb02 | 2026-09-27 |
| 35832749634 | 5ce0c88 | 2026-09-23 |
| 35226039783, 35203003478, 35202959189, 35202916978 | 8624f86, 398046b, 28f683e, 98764ba | 2026-09-17 |
Why it matters. The docs promise otherwise: ci.yml's semver comment says "every push to main", and RELEASING.md:46-50 says every push to main "is checked a second time … against the commit it lands on". The semver gate's second check (#598) compares BASE_REV = github.event.before with the pushed commit. When that commit's run is dropped, the next run compares against the dropped commit, which already contains its change. A second break that only the dropped run would have caught goes through.
Fix. Give main a per-commit group, for example group: ci-${{ github.workflow }}-${{ github.ref == 'refs/heads/main' && github.sha || github.ref }}. Do the same in commit-policy.yml, and set its cancel-in-progress false on main. Or soften the docs to what is actually guaranteed.
Done when every commit pushed to main gets a CI run, checked the next time two merges land close together.
- Dominant language
- Rust
- Stars
- 28
- Forks
- 24
- Avg merge
- 11h 23m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
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 vyncint/termlens
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
Release notes show a broken link: `extract-changelog.sh` copies a reference but not its definitionOpenbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
All issues in vyncint/termlens
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Y-ASLant/ElegantClipboard#178 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
linxiv-dev/linXiv#384 · 1 comment ·
Maintainers usually reply within 1 day
-
bug drawings ui
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
userFRM/egui-charts#1595 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
smoltcp-rs/smoltcp#1235 ·
Maintainers usually reply within 1 day
-
scope:core type:security
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day