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

bleedingdeacons / rabbit / 33970647988
65%

Build:
DEFAULT BRANCH: main
Ran 05 Sep 2026 02:06PM UTC
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

05 Sep 2026 02:02PM UTC coverage: 47.776%. Remained the same
33970647988

push

github

web-flow
fix: push the release commit first, rebase only if it is rejected

This job already rebased before pushing, so it was never exposed the way
Link's was — this is an upgrade to that, not a fix for a hole.

Rebasing first closes the long window, the minutes spent building, but
leaves a short one between the pull and the push, and nothing retried
it. Pushing first and rebasing only on rejection leaves no gap at all.

What the old form would eventually have cost is what Link actually paid
on 2026-09-05: a merge landed sixteen seconds before its push, git
refused the non-fast-forward, and the release died with every gate
already green. Nothing broke and nothing was published; the version was
simply lost, and the next release skipped a number to catch up. Link's
job had no rebase whatever, which is why it was the one that got caught.

The race is never two release jobs — the concurrency group serialises
those. It is a person merging while one is in flight, and the other
writer is not a job, so no job-level concurrency can see it.

A conflict is deliberately not retried. That matters slightly more here
than in Link, because the release commit spans the plugin header,
readme.txt, README.md and the bundled docs rather than one csproj line,
so there is more surface to collide with. The behaviour is unchanged
from today either way: the step fails, nothing is pushed, and the rebase
is aborted so the tree is not left mid-rebase.

The sha output is read after the loop on purpose. A rebase rewrites the
commit, and the release is published against that sha, so reading it
before the retry would point the release at a commit that never landed.

Verified against a simulated race in throwaway repos rather than by
inspection:

  - a merge touching an unrelated file lands first: attempt 1 rejected,
    rebase, attempt 2 succeeds, the version lands, and the sha written to
    GITHUB_OUTPUT matches the commit that actually ended up on main.
  - a merge touching the version fi... (continued)

247 of 517 relevant lines covered (47.78%)

2.38 hits per line

Jobs
ID Job ID Ran Files Coverage
1 33970647988.1 05 Sep 2026 02:06PM UTC 17
47.78
GitHub Action Run
Source Files on build 33970647988
  • Tree
  • List 17
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #33970647988
  • bed10a9a on github
  • Prev Build on main (#32901279605)
  • Next Build on main (#33975388603)
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