feat: use composer's --no-security-blocking flag

[Chris53897]

check ci for lowest run

With the new composer version the runs for older minor symfony version like 7.1 fail

Solutions

• use older composer version
• configure composer to allow unsecured versions
• drop tests for symfony 7.0, 7.1, 7.2 tests
• ?

Summary by CodeRabbit

• Documentation

  • Added a short line to the README for CI/reference.

• Chores

  • Updated CI workflow configuration for dependency installation options to alter installation behavior.

[coderabbitai]

Walkthrough

Appends a standalone "check ci" line to README.md and adds the --no-security-blocking flag to the composer options used by the GitHub Actions integration-tests workflow (ramsey/composer-install@v3). No public API or application logic changes.

Changes

Cohort / File(s)	Change Summary
Documentation README.md	Appended a single standalone line: "check ci".
CI workflow .github/workflows/tests.yml	Added --no-security-blocking to the composer-options passed to ramsey/composer-install@v3 during dependency installation in the integration-tests job.

Sequence Diagram(s)

sequenceDiagram
    participant GH as GitHub Actions
    participant Composer as ramsey/composer-install@v3
    note right of GH#ffefc2: integration-tests job
    rect rgba(214,245,214,0.3)
    GH->>Composer: run composer install\n(old: without --no-security-blocking)
    end
    rect rgba(255,239,194,0.3)
    GH->>Composer: run composer install\n(new: with --no-security-blocking)
    end
    note right of Composer#d6f5d6: installer skips security-blocking checks when flag present

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Inspect .github/workflows/tests.yml to confirm the --no-security-blocking flag is added only to the intended composer-install step and no other workflow logic or arguments were changed.

Poem

🐰 A hop, a line, a tiny try,
"check ci" beneath the README sky.
I nudged a flag in workflow land,
Composer skips a blocking stand.
A rabbit's note — light, quick, and spry.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title focuses on adding the --no-security-blocking flag, which aligns with the implemented changes in the workflow file.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 781bc60 and 9fe6fb9.

📒 Files selected for processing (1)

• README.md (1 hunks)

[norkunas]

• configure composer to allow unsecured versions

sounds best to me

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/tests.yml (1)

95-101: Consider conditional application of the security flag for targeted testing.

If the primary goal is to ensure the "lowest" supported versions work (as stated in the PR objective), the --no-security-blocking flag could be applied conditionally only to those specific runs rather than globally to all dependency scenarios.

This would reduce security exposure during testing while still achieving the PR's goal of validating the lowest-supported environment.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9fe6fb9 and b41ff27.

📒 Files selected for processing (1)

• .github/workflows/tests.yml (1 hunks)

🔇 Additional comments (1)

.github/workflows/tests.yml (1)

100-100: Approved: --no-security-blocking is correctly configured.

The --no-security-blocking flag is a documented Composer option that allows installing packages with security advisories or that are abandoned. The ramsey/composer-install action accepts this flag via the composer-options input parameter, and your usage is correct.

The flag is applied globally to all matrix runs (default, lowest, highest dependencies). While this is broader than strictly necessary, it's a valid design choice for simplicity in CI testing scenarios. Note that COMPOSER_NO_SECURITY_BLOCKING takes precedence and forces all security blocking to be disabled, including abandoned package blocking.

For testing purposes, this approach is acceptable—security checks in CI are less critical than in production deployments.

[Chris53897]

i will wait for composer/composer#12612

[norkunas]

@Chris53897 composer already released new version

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.38%. Comparing base (deb6127) to head (b05b9fe).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #409   +/-   ##
=======================================
  Coverage   88.38%   88.38%           
=======================================
  Files          20       20           
  Lines         878      878           
=======================================
  Hits          776      776           
  Misses        102      102           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[norkunas]

Thank you @Chris53897