Skip to content

chore(deps): update PHP dependencies [full-ci]#41673

Open
phil-davis wants to merge 1 commit into
masterfrom
php-dependencies-20260709
Open

chore(deps): update PHP dependencies [full-ci]#41673
phil-davis wants to merge 1 commit into
masterfrom
php-dependencies-20260709

Conversation

@phil-davis

Copy link
Copy Markdown
Contributor
  • Upgrading guzzlehttp/guzzle (7.13.2 => 7.14.0)
  • Upgrading guzzlehttp/promises (2.5.0 => 2.5.1)
  • Upgrading guzzlehttp/psr7 (2.12.3 => 2.12.4)
  • Upgrading roave/security-advisories (dev-latest 4d2ca57 => dev-latest 1c42f8a)
  • Upgrading sabre/event (5.1.8 => 5.1.9)

Note: this gets the last of the recently-released sabre dependencies. I have asked for full-ci so that both unit tests and all the API acceptance tests will run in CI (just to be sure that there is no obvious regression).

- Upgrading guzzlehttp/guzzle (7.13.2 => 7.14.0)
- Upgrading guzzlehttp/promises (2.5.0 => 2.5.1)
- Upgrading guzzlehttp/psr7 (2.12.3 => 2.12.4)
- Upgrading roave/security-advisories (dev-latest 4d2ca57 => dev-latest 1c42f8a)
- Upgrading sabre/event (5.1.8 => 5.1.9)
@phil-davis phil-davis requested a review from a team as a code owner July 9, 2026 06:42

@dj4oC dj4oC left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Routine PHP dependency refresh: bumps guzzlehttp/guzzle 7.13.2→7.14.0, guzzlehttp/promises 2.5.0→2.5.1, guzzlehttp/psr7 2.12.3→2.12.4, sabre/event 5.1.8→5.1.9, and roave/security-advisories (advisory-DB refresh). Only composer.lock and the changelog entry change.

Branch target

oC11 / master — in scope. ✓ (Author is @phil-davis, not Dependabot, so the Dependabot auto-merge fast-lane does not apply — this needs the normal human approval.)

Review passes

  • Security: no findings, net-positive. All updated packages are permissive-licensed (guzzle* MIT, sabre/event BSD-3, roave MIT) — no GPL/AGPL, no replace local-path directives. roave/security-advisories moves forward and tightens conflict constraints (e.g. web-auth/webauthn-lib, egroupware/egroupware, code16/sharp), which strengthens CVE blocking rather than introducing one. No known CVE introduced by the guzzle/sabre bumps.
  • Stability: no findings. Patch/minor bumps of mature libraries; no first-party code touched. PHP Unit passed on all 5 DB engines and the acceptance shards that completed were green.
  • Performance: no findings.
  • Test coverage: N/A for a lockfile-only change — no application code added, so the 85% gate does not apply.
  • Dependabot coverage: .github/dependabot.yml covers the composer ecosystem at / (where composer.json / composer.lock live) — ✓ no gap.

CI status — red, but spurious (infra abort, not a regression)

The failing checks belong to CI run attempt #2 (a manual re-run), whose jobs all terminated with The runner has received a shutdown signal … operation was canceled during PHP setup, before any test executed — a GitHub Actions runner preemption, not a test or dependency failure. Attempt #1's PHP Unit (all 5 DBs) and the acceptance shards that ran were green, and license/cla is green.

Recommended action: re-run the CI workflow (Actions → run 28999405727 → "Re-run failed jobs"). I attempted the re-run automatically, but the review integration lacks actions:write permission (403 Resource not accessible by integration), so a maintainer needs to trigger it.

Quality gates

  • Security: no findings
  • Stability: no findings
  • Performance: no findings
  • Test coverage: n/a (lockfile-only change)
  • TODOs found: none
  • Dependency touched: yes — composer; confirmed covered in .github/dependabot.yml
  • CI status: failing (CI attempt #2) — spurious runner-shutdown abort during setup, not a code failure; re-run recommended
  • Stale review: no

Verdict

Commenting — no code findings; the only issue is a spurious CI runner abort. Re-run CI for a clean green. Already human-approved by @DeepDiver1975.

🤖 Automated review by Claude Code (security · stability · performance · coverage)


Generated by Claude Code

@dj4oC dj4oC left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI update — correcting my earlier review

Retraction: my previous review (08:46Z) characterized the red CI as a spurious runner shutdown during setup and recommended simply re-running for a "clean green." A re-run of workflow 28999405727 has since executed at ~10:55Z, and that characterization no longer holds — the jobs actually ran to completion and 3 acceptance suites failed for real (not setup aborts). Please do not merge on the strength of my earlier "just re-run it" note.

Verified CI state (latest attempt, run 28999405727)

  • Failed (ran full duration, real failures):
    • API Tests / apiShareOperationsToRoot1,apiShareOperationsToRoot2 (ran ~25 min)
    • API Tests Federation / apiFederationToRoot1,apiFederationToRoot2
    • CLI Tests / cliBackground,cliMain,cliManageApps,cliTrashbin
  • The remaining ~20 API shards show cancelled — that is fail-fast cancellation triggered by the above, not independent passes.
  • license/cla: green. PHP Unit (attempt 1): green.

Root cause — not yet confirmed

I inspected the job logs but could not extract the behat scenario-level assertion (it sits above a very large trailing artifact dump). What I can say:

  • The failures span three unrelated suites (sharing, federation, CLI) that all started in the same ~10:55Z runner batch — a pattern more consistent with shared-infra flakiness (runner/DB contention) than a single code regression.
  • The Apache access logs I sampled show requests completing with normal status codes (200/201/207, plus expected 404s), i.e. no obvious GuzzleHttp 5xx/stack-trace signature — so there is no positive evidence yet of a guzzle/sabre regression, but it cannot be ruled out either.

Recommended next step (needs a maintainer — I lack actions:write)

  1. Re-run the failed jobs once more. If all three go green, this was infra flakiness and the PR is clean.
  2. If any suite fails again on a clean re-run, download the behat report artifact for that shard to get the failing scenario — a guzzle 7.13→7.14 / sabre-event 5.1.9 behavioral change reaching the federation/sharing HTTP paths would be the thing to check.

Because this is a dependency bump whose current failures touch federation and sharing (both escalate-to-human areas), I am not auto-fixing and not approving until CI is genuinely green.

Quality gates

  • Security: no findings (dependency licenses permissive; roave advisory-DB tightened, not loosened)
  • Stability: CI failing — 3 acceptance suites (sharing / federation / CLI) red on latest re-run; root cause unconfirmed (flaky-infra vs regression)
  • Performance: no findings
  • Test coverage: n/a (lockfile-only change)
  • TODOs found: none
  • Dependency touched: yes — composer; confirmed covered in .github/dependabot.yml
  • CI status: failing — API Tests (apiShareOperationsToRoot), API Tests Federation (apiFederationToRoot), CLI Tests (cliMain et al.)
  • Stale review: no

Verdict

Commenting — no code findings, but not mergeable while CI is red. Not the Dependabot fast-lane (author is @phil-davis). Needs a clean re-run and a human decision before merge.

🤖 Automated review by Claude Code (security · stability · performance · coverage)


Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants