mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-12 06:48:55 +00:00
7045da7450
c05927c1added a `concurrency:` block on the premise that the suite never got one. It already had one, four lines above -- the hunk header of that diff reads `@@ -50,6 +50,23 @@ concurrency:`, which is the existing block it was appended below. A YAML mapping cannot carry the same key twice, so the file has not loaded since. GitHub still creates a run and then schedules nothing:553f5fd2(last green) run 33036453748 jobs=1 ci -> successd58e4830(main) run 33114046849 jobs=0 failure Every run since has that shape, and the run list names it in passing: those runs appear as `.github/workflows/tests.yml` where the green ones appear as `tests`, because the `name:` key sits inside the file that did not parse. `linter` is unaffected -- it carries one block -- which is why351da21eshows a green linter beside a failed tests run, and the tree reads as half-checked rather than unchecked. Reproduced with a parser rather than inferred from the job count: before -> THREW: Duplicate key "concurrency" detected at line 66. after -> parsed ok, top-level keys: name,on,concurrency,jobs Kept the second block, verbatim, because it is the onec05927c1meant to end up with and its comment carries the reasoning -- including the tradeoff that an intermediate commit on `main` can end up with no run of its own. The two group keys are interchangeable: `github.workflow` is constant within a workflow, so `tests-${{ github.workflow }}-${{ github.ref }}` and `tests-${{ github.ref }}` produce the same grouping. Worth knowing that lint.yml still uses the first shape, if you would rather the two files read alike. No test. The failure is loud on the next push, and a test that parses a workflow file would be a second place to keep the same rule.