boost-skill-cli 1.0.304__tar.gz → 1.0.305__tar.gz

{boost_skill_cli-1.0.304/boost_skill_cli.egg-info → boost_skill_cli-1.0.305}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.304
+Version: 1.0.305
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.304 → boost_skill_cli-1.0.305}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.304'
-__version_tuple__ = version_tuple = (1, 0, 304)
+__version__ = version = '1.0.305'
+__version_tuple__ = version_tuple = (1, 0, 305)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.304 → boost_skill_cli-1.0.305/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.304
+Version: 1.0.305
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.304 → boost_skill_cli-1.0.305}/boost_skill_cli.egg-info/SOURCES.txt

@@ -546,6 +546,7 @@ tests/unit/test_typosquat.py
 tests/unit/test_updatediff.py
 tests/unit/test_util.py
 tests/unit/test_version.py
+tests/unit/test_workflow_concurrency.py
 tests/unit/test_workflow_timeouts.py
 tests/unit/test_workflows.py
 tests/visual/a11y_check.mjs

boost_skill_cli-1.0.305/docs/roadmap/items/ci-time-is-now-runner-queueing.md

@@ -0,0 +1,71 @@
+---
+id: ci-time-is-now-runner-queueing
+board: code
+section: pipeline
+status: shipped
+category: CI speed
+complexity: M
+impact: High
+wow: 4
+note: 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
+order: 62
+owner: loop/ci-concurrency
+pr: 350
+title: A third of CI job time is spent waiting for a runner, not running
+---
+With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
+<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
+job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
+time spent waiting for a runner.
+
+<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
+<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
+Queueing happens per <em>job</em>, not per run, so it is only visible as
+<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
+conclude, wrongly, that there is nothing to fix.
+
+The per-run spread shows what drives it &mdash; median job queue by run:
+<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
+<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
+That is a 29&times; swing driven not by the change under test but by how many sibling
+<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
+one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
+
+Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
+is the right trade for latency in isolation, and the wrong one to keep making blindly while a
+dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
+roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
+superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
+count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
+fix.
+
+<b>Shipped: the least intrusive one, and it turned out to be a plain omission rather than a
+trade-off.</b> Seven workflows here already declare a <code>concurrency</code> group.
+<code>ci.yml</code> &mdash; the largest by a wide margin, ~36 checks including six mutation
+shards &mdash; declared none, so every push to a pull request left the whole previous run
+executing against a commit nobody was waiting on. This session alone pushed four times to one PR,
+which is 24 shard jobs of which 18 were already superseded.
+
+Two things keep the release path out of it, and the second is easy to miss. The <b>condition</b>:
+<code>cancel-in-progress: true</code> would also cancel a push to main, which
+<code>publish.yml</code> gates the release on via <code>workflow_run</code> &mdash; a merge that
+silently never ships &mdash; and a <code>merge_group</code> run, where a cancelled run never
+reports its required contexts and the queue then waits forever on a status that is not coming.
+Both evaluate false.
+
+The <b>key</b>: non-PR events group on <code>github.sha</code>, not <code>github.ref</code>.
+<code>cancel-in-progress: false</code> does not mean "never cancel" &mdash; it means a newer run
+<i>waits</i>, and GitHub cancels the older <em>pending</em> run when a third arrives. Keying main
+on its ref would put every main push in one group, so three quick merges would leave a middle
+commit whose <code>ci</code> never completes, and since <code>publish.yml</code> fires on
+<code>workflow_run</code> of <code>ci</code>, that commit would never release. A sha is unique per
+commit, so main and the merge queue never share a group at all.
+
+Both properties are pinned by tests rather than by the comment, and a separate assertion sweeps
+every workflow that triggers on <code>merge_group</code> and fails if any cancels unconditionally
+&mdash; so the deadlock cannot arrive later through a different file.
+
+What this does <em>not</em> do is reduce the footprint of a single run, which is the other half of
+the measurement. <code>max-parallel</code> on the shard matrix and an adaptive shard count are
+still open, and both trade latency for footprint rather than removing waste &mdash; worth
+re-measuring queue time after this lands before spending that trade.

{boost_skill_cli-1.0.304 → boost_skill_cli-1.0.305}/docs/roadmap.html

@@ -2623,7 +2623,7 @@ missing file is now imputed at the measured mean rate, which keeps every weight
       </article>
 
       <article class="cap rcard" id="ci-time-is-now-runner-queueing">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI speed</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI speed</span></div>
         <h3>A third of CI job time is spent waiting for a runner, not running</h3>
         <p>With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
 <b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
@@ -2649,7 +2649,38 @@ dozen branches are in flight, because every concurrent PR now multiplies its foo
 roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
 superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
 count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
-fix.</p>
+fix.
+
+<b>Shipped: the least intrusive one, and it turned out to be a plain omission rather than a
+trade-off.</b> Seven workflows here already declare a <code>concurrency</code> group.
+<code>ci.yml</code> &mdash; the largest by a wide margin, ~36 checks including six mutation
+shards &mdash; declared none, so every push to a pull request left the whole previous run
+executing against a commit nobody was waiting on. This session alone pushed four times to one PR,
+which is 24 shard jobs of which 18 were already superseded.
+
+Two things keep the release path out of it, and the second is easy to miss. The <b>condition</b>:
+<code>cancel-in-progress: true</code> would also cancel a push to main, which
+<code>publish.yml</code> gates the release on via <code>workflow_run</code> &mdash; a merge that
+silently never ships &mdash; and a <code>merge_group</code> run, where a cancelled run never
+reports its required contexts and the queue then waits forever on a status that is not coming.
+Both evaluate false.
+
+The <b>key</b>: non-PR events group on <code>github.sha</code>, not <code>github.ref</code>.
+<code>cancel-in-progress: false</code> does not mean "never cancel" &mdash; it means a newer run
+<i>waits</i>, and GitHub cancels the older <em>pending</em> run when a third arrives. Keying main
+on its ref would put every main push in one group, so three quick merges would leave a middle
+commit whose <code>ci</code> never completes, and since <code>publish.yml</code> fires on
+<code>workflow_run</code> of <code>ci</code>, that commit would never release. A sha is unique per
+commit, so main and the merge queue never share a group at all.
+
+Both properties are pinned by tests rather than by the comment, and a separate assertion sweeps
+every workflow that triggers on <code>merge_group</code> and fails if any cancels unconditionally
+&mdash; so the deadlock cannot arrive later through a different file.
+
+What this does <em>not</em> do is reduce the footprint of a single run, which is the other half of
+the measurement. <code>max-parallel</code> on the shard matrix and an adaptive shard count are
+still open, and both trade latency for footprint rather than removing waste &mdash; worth
+re-measuring queue time after this lands before spending that trade.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>

boost_skill_cli-1.0.305/tests/unit/test_workflow_concurrency.py

@@ -0,0 +1,112 @@
+"""Unit tests: superseded PR runs are cancelled, releases never are.
+
+Measured over six consecutive successful ``ci`` runs, **31%** of all job time
+was spent queueing rather than executing (104 job-minutes against 236). The
+median per-job queue swung 29x between runs — 0.1 min when the repo was quiet,
+2.9 min when a dozen ``loop/*`` branches and Dependabot PRs were live — so the
+cost is driven by concurrent footprint, not by the change under test. Sharding
+the mutation gate traded one runner slot for six and made that worse on purpose.
+
+``ci.yml`` is the largest workflow in the repo by a wide margin, and it was the
+only one with no ``concurrency`` group at all: every push to a pull request left
+the previous run's ~36 checks (six of them mutation shards) running to
+completion against nothing.
+
+The dangerous half of the fix is the half these tests pin. Cancelling a
+**pull_request** run that a newer push superseded costs nothing. Cancelling a
+**push to main** would abandon the run ``publish.yml`` gates the release on, and
+cancelling a **merge_group** run would leave a required check permanently
+unreported and deadlock the queue — the exact failure mode ci.yml's own comments
+describe. So cancellation must be conditional on the event, and that condition
+is what a future edit is most likely to get wrong.
+"""
+from __future__ import annotations
+
+import re
+from pathlib import Path
+
+import pytest
+
+WORKFLOWS = Path(__file__).resolve().parents[2] / ".github" / "workflows"
+CI = WORKFLOWS / "ci.yml"
+
+pytestmark = pytest.mark.skipif(
+    not CI.exists(),
+    reason=".github/workflows not reachable (e.g. mutation sandbox)")
+
+
+def concurrency_block(path: Path) -> str:
+    """The top-level ``concurrency:`` mapping of a workflow, or ''.
+
+    Top-level only: a job-level block is indented and must not be mistaken for
+    the workflow's own policy.
+    """
+    text = path.read_text(encoding="utf-8")
+    m = re.search(r"^concurrency:\s*$\n((?:^[ \t]+\S.*\n|^\s*#.*\n)*)", text, re.M)
+    return m.group(1) if m else ""
+
+
+class TestCiCancelsSupersededRuns:
+    def test_ci_declares_a_concurrency_group(self):
+        assert concurrency_block(CI), \
+            "ci.yml is the biggest workflow here; without a concurrency group " \
+            "every superseded push keeps ~36 checks running against nothing"
+
+    def test_the_group_is_per_pull_request(self):
+        # Keyed on the PR number so two PRs never cancel each other.
+        assert "github.event.pull_request.number" in concurrency_block(CI)
+
+    def test_non_pr_events_group_on_the_commit_not_the_ref(self):
+        # THE SUBTLE ONE. `cancel-in-progress: false` does not mean "never
+        # cancel" — it means a newer run waits, and GitHub cancels the older
+        # *pending* run when a third arrives. Keying main on `github.ref` puts
+        # every main push in one group, so three quick merges would leave a
+        # middle commit whose ci never completes; publish.yml fires on
+        # `workflow_run` of ci, so that commit would never release. A sha is
+        # unique per commit, so main and the merge queue never share a group.
+        block = concurrency_block(CI)
+        assert "github.sha" in block, block
+        assert "github.ref" not in block, \
+            "grouping non-PR runs on the ref can strand a main commit unreleased"
+
+    def test_cancellation_is_conditional_not_unconditional(self):
+        # `cancel-in-progress: true` would cancel main and merge_group runs too.
+        block = concurrency_block(CI)
+        m = re.search(r"cancel-in-progress:\s*(.+)", block)
+        assert m, "no cancel-in-progress in %r" % block
+        value = m.group(1).strip()
+        assert value not in ("true", "'true'", '"true"'), \
+            "unconditional cancel would abandon the run publish.yml gates on"
+        assert "pull_request" in value, value
+
+    def test_only_pull_request_events_are_cancelled(self):
+        # The whole safety property in one assertion: the guard names
+        # pull_request, so push-to-main and merge_group evaluate false.
+        value = re.search(r"cancel-in-progress:\s*(.+)",
+                          concurrency_block(CI)).group(1)
+        assert "github.event_name == 'pull_request'" in value, value
+
+
+class TestReleasePathIsNeverCancelled:
+    def test_publish_does_not_cancel_in_progress(self):
+        # Every merge to main cuts a PyPI release; cancelling a release run
+        # mid-upload is how you get a tagged version that never shipped.
+        block = concurrency_block(WORKFLOWS / "publish.yml")
+        assert "cancel-in-progress: false" in block, block
+
+    def test_no_workflow_cancels_a_merge_group_run(self):
+        # A required context whose run is cancelled never reports, and the
+        # merge queue waits on it forever. Any workflow that both triggers on
+        # merge_group and cancels unconditionally is that deadlock waiting to
+        # happen.
+        offenders = []
+        for path in sorted(WORKFLOWS.glob("*.yml")):
+            text = path.read_text(encoding="utf-8")
+            if not re.search(r"^\s*merge_group:", text, re.M):
+                continue
+            block = concurrency_block(path)
+            if re.search(r"cancel-in-progress:\s*true\s*$", block, re.M):
+                offenders.append(path.name)
+        assert not offenders, \
+            "these cancel merge_group runs and would deadlock the queue: %s" \
+            % ", ".join(offenders)

boost_skill_cli-1.0.304/docs/roadmap/items/ci-time-is-now-runner-queueing.md

@@ -1,40 +0,0 @@
----
-id: ci-time-is-now-runner-queueing
-board: code
-section: pipeline
-status: planned
-category: CI speed
-complexity: M
-impact: High
-wow: 4
-note: 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
-order: 62
-owner:
-pr:
-title: A third of CI job time is spent waiting for a runner, not running
----
-With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
-<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
-job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
-time spent waiting for a runner.
-
-<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
-<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
-Queueing happens per <em>job</em>, not per run, so it is only visible as
-<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
-conclude, wrongly, that there is nothing to fix.
-
-The per-run spread shows what drives it &mdash; median job queue by run:
-<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
-<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
-That is a 29&times; swing driven not by the change under test but by how many sibling
-<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
-one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
-
-Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
-is the right trade for latency in isolation, and the wrong one to keep making blindly while a
-dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
-roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
-superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
-count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
-fix.