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

bleedingdeacons / unity / 31052220554
96%

Build:
DEFAULT BRANCH: main
Ran 05 Aug 2026 10:18PM UTC
Jobs 1
Files 8
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 Aug 2026 10:18PM UTC coverage: 94.079%. Remained the same
31052220554

push

github

web-flow
fix(build): stop the readme and version syncs stripping carriage returns (#47)

Every line-rewriting sync in build.php matched its line tail as `.+$` — the
readme.txt Stable tag and Build date rewrites, the README.md **Version:** line,
and in sentinel the sentinel-logger.php Version header. In PCRE `.` matches \r,
so on a CRLF file `.+$` eats the carriage return and the replacement writes the
line back LF-only, leaving one mixed line ending behind. The Build date insert
path had the same fault from the other side: `(Stable tag:[ \t]*.+)(\r?\n)`
let the CR fall into group 1, so the newly inserted line got an LF while its
neighbours kept CRLF.

This is what broke sentinel earlier today. Its build date goes into
sentinel.php rather than readme.txt, and the root plugin file is now in the
PSR-12 scan, so a plain build was enough to fail the gate. The readme.txt and
README.md cases never surfaced because .gitattributes (* text=auto) normalises
both to LF on check-in — the damage lived only in the Windows working copy
between a build and the commit that followed it. Fixing them anyway: the fault
is the same one, and the next sync pointed at a scanned file would fail the
same way.

Matching `[^\r\n]*` is not sufficient on its own. In multiline mode `$` anchors
before \n and not before \r, so a bare `[^\r\n]*$` never matches a CRLF line at
all and the sync silently stops working — the date quietly stops being stamped
and nothing reports it. The CR has to be stepped over with a `(?=\r?$)`
lookahead instead. `\s*` before the tail is narrowed to `[ \t]*` for the same
reason: `\s` matches \r and \n, so it could run past the end of the line.

Verified by running a production build: every sync still reports Updated rather
than skipping, and readme.txt, README.md and the plugin file all come back with
uniform line endings.

143 of 152 relevant lines covered (94.08%)

3.09 hits per line

Jobs
ID Job ID Ran Files Coverage
1 31052220554.1 05 Aug 2026 10:18PM UTC 8
94.08
GitHub Action Run
Source Files on build 31052220554
  • Tree
  • List 8
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #31052220554
  • dccc618d on github
  • Prev Build on main (#31051275304)
  • Next Build on main (#31052714303)
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