• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

bleedingdeacons / hand / 33969612125
93%

Build:
DEFAULT BRANCH: main
Ran 05 Sep 2026 01:41PM UTC
Jobs 1
Files 16
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

05 Sep 2026 01:41PM UTC coverage: 92.465%. Remained the same
33969612125

push

github

web-flow
fix: rebase and retry the version push instead of losing the release

Hand's version job is Link's, ported, so it carried the identical
exposure and had simply not been unlucky yet.

A bare `git push` here fails outright when main has moved between the
job's checkout and this line. On 2026-09-05 that cost Link a whole
release: a merge landed sixteen seconds before the push, git refused the
non-fast-forward, and the run died at "Commit the new version" with
every gate already green. Nothing broke and nothing was published; the
version was lost, and the next release skipped a number to catch up.

The concurrency group above serialises this job against itself, so the
race is never two version jobs. It is a person merging while one is in
flight, which no amount of job-level concurrency can prevent — the other
writer is not a job.

Rebasing is safe for the version this job computed. The bump is derived
from the commit range the run was triggered for, and commits arriving
meanwhile are not in that range: they get their own run and their own
bump. Landing this commit on top of them skips nothing and
double-counts nothing.

A conflict is deliberately not retried. The only way to conflict is
another writer touching the same version line, which the concurrency
group already rules out for this job, so it means something genuinely
unexpected — better to fail loudly than resolve it blind. The rebase is
aborted first so the tree is not left mid-rebase.

Identical to the fix in Link, verified there against a simulated race in
two throwaway repos: a merge landing first is recovered on the second
attempt with the other writer's change intact, and a genuine conflict on
the version line exits 1 leaving no rebase in progress and origin
untouched. The parsed YAML of the two steps was diffed to confirm the
logic matches line for line.

Note the nineteen plugin repos already solve this, a shorter way: an
unconditional `git pull --rebase` before the push. That closes the lon... (continued)

1313 of 1420 relevant lines covered (92.46%)

1332.53 hits per line

Jobs
ID Job ID Ran Files Coverage
1 33969612125.1 05 Sep 2026 01:41PM UTC 16
92.46
GitHub Action Run
Source Files on build 33969612125
  • Tree
  • List 16
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #33969612125
  • 3e2e5369 on github
  • Prev Build on main (#33541189647)
  • Next Build on main (#33975354489)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc