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

bleedingdeacons / confur / 30923972392
95%

Build:
DEFAULT BRANCH: main
Ran 04 Aug 2026 03:27PM 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

04 Aug 2026 03:24PM UTC coverage: 90.884%. Remained the same
30923972392

push

github

web-flow
Commit composer.lock and add Dependabot (#41)

* chore(ci): add Dependabot configuration

Two ecosystems, worth very different amounts here.

github-actions is the useful one: every workflow pins actions/checkout,
shivammathur/setup-php, actions/cache and coverallsapp/github-action to a major
tag, and nothing else notices when one goes stale or picks up a security fix.

composer is deliberately limited. composer.lock is gitignored across all
seventeen plugins, so CI resolves from composer.json on every run. With no lock
to update, Dependabot can only bump the constraint — it fires when a release
lands outside the declared range (PHPUnit 11 against ^10.5) and stays silent
when one lands inside it (PHPStan 2.2.8 against ^2.0). The second case is what
breaks a committed phpstan-baseline.neon, and Dependabot cannot see it; pinning
tool versions in CI is the answer to that, not this file. The reasoning is in
the config header so it is not rediscovered later.

Both ecosystems are monthly and grouped: seventeen repositories on a weekly
ungrouped schedule is a great deal of noise for a suite whose dependencies
already float.

* chore(ci): commit composer.lock and add Dependabot

These are one decision. Dependabot's composer ecosystem is nearly useless
without a lock: with none it can only bump the constraint in composer.json, so
it fires when a release lands outside the declared range (PHPUnit 11 against
^10.5) and stays silent when one lands inside it (PHPStan 2.2.8 against ^2.0).
The second case is what breaks a committed phpstan-baseline.neon, and it was
invisible to CI and Dependabot alike.

Tracking the lock fixes the underlying problem too. CI ran composer install
with no lock, so every build resolved afresh against whatever had been
published that morning, and two runs of the same commit could disagree.

The lock was regenerated where it needed to be rather than committed as found —
a stale lock pins CI to old versions, which is worse than none. Of the... (continued)

977 of 1075 relevant lines covered (90.88%)

2.3 hits per line

Jobs
ID Job ID Ran Files Coverage
1 30923972392.1 04 Aug 2026 03:27PM UTC 16
90.88
GitHub Action Run
Source Files on build 30923972392
  • 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 #30923972392
  • e2214402 on github
  • Prev Build on main (#30756987886)
  • Next Build on main (#30925509991)
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