bleedingdeacons / hand / 34365271848
93%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 17
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 92.769%. Remained the same
34365271848

push

github

web-flow 
fix(ci): recompute the version when the push loses the race (#55)

The version job could silently drop a release. It computed the next
version from the csproj at checkout, committed it, and on a rejected
push rebased that commit onto whatever had landed meanwhile. Both sides
edit the same ApplicationDisplayVersion line, so the rebase conflicted
every time -- and a conflict was deliberately not retried, so the job
aborted with the version lost.

On 2026-09-09 the runs for #52 and #53 both computed against 1.17.2.
#53 pushed 1.18.0; #52's 1.17.3 conflicted and vanished, leaving a red
run on main with all four quality gates green. That is the whole of the
symptom: nothing about it looks like a versioning problem.

The comment claiming this could not happen argued that the `version-main`
concurrency group rules out a second writer. It does serialise the job
against itself -- but each run computes its number from a checkout taken
before the other pushed, so serialising when they *run* leaves both
numbers stale. The staleness is established at checkout, which job-level
concurrency cannot reach.

So stop replaying a stale commit and recompute instead. On rejection the
job now discards its commit, resets onto origin/main, and bumps again
from the same range -- pinned to concrete SHAs up front, because a range
ending in the literal HEAD would start naming somebody else's commits
after the reset, which is how a bump comes to double-count. #52's fix
recomputed against 1.18.0 gives 1.18.1: its own version, nothing skipped
and nothing counted twice. The bump type still comes from the range, so
a feat still takes a minor.

bump-version.sh refuses to bump on top of a version commit, which is
exactly what the reset lands on, so HAND_BUMP_ON_VERSION_COMMIT=1 lifts
that guard on this one path. The retry loop's three attempts bound it,
and the guard is otherwise untouched -- it still closes the loop on the
job's own push and on a re-run of an older one.

Two steps becam... (continued)

1360 of 1466 relevant lines covered (92.77%)

1292.27 hits per line

Jobs
ID Job ID Ran Files Coverage
1 34365271848.1 17
92.77
GitHub Action Run
Source Files on build 34365271848