Trust project configuration files in Behat runs

[swissspidy]

Companion to wp-cli/wp-cli#6365.

That PR gates require, exec, env and ssh-args directives found in a project-level wp-cli.yml behind a trust confirmation, controlled by --trust-project-config / WP_CLI_TRUST_PROJECT_CONFIG.

Test fixtures create such files all the time — Given a wp-cli.yml file: with a require: entry is one of the most common steps across the WP-CLI package suites, and given_a_request_to_a_url_respond_with_file() writes one itself. A Behat run is non-interactive, so without this change every one of those scenarios fails with:

Error: Untrusted project configuration file '…/wp-cli.yml' contains 'require' directive(s).
Run interactively to confirm, or set WP_CLI_TRUST_PROJECT_CONFIG=true / add path to system or
global config file to allow execution.

Changes

• FeatureContext::get_process_env_variables() now passes WP_CLI_TRUST_PROJECT_CONFIG=1 to every command it runs. An explicit value in the outer environment still wins, following the same pass-through pattern already used for WP_CLI_CONFIG_PATH, WP_CLI_ALLOW_ROOT and friends.
• Documented the behaviour in the README, including how a scenario overrides it per command (When I try \WP_CLI_TRUST_PROJECT_CONFIG=false wp cli version``), which is how the trust mechanism's own acceptance tests in Add project configuration trust verification (trust-project-config) wp-cli#6365 exercise the denial paths.

Testing

Ran the affected wp-cli/wp-cli feature scenarios against a checkout of wp-cli/wp-cli#6365 with this context patched in: the 28 scenarios that build a project wp-cli.yml containing require/exec/env/ssh-args and do not need a WordPress install (across command, config, flags, prompt, runcommand and runner features) fail without this change and pass with it. The nine new trust scenarios in features/config.feature still pass, confirming that the per-command override keeps working.

Note this needs to be released before wp-cli/wp-cli#6365's CI can go green, since that repo installs wp-cli/wp-cli-tests from a version constraint.

---

Generated by Claude Code

Summary by CodeRabbit

• New Features

  • Behat test processes now automatically trust project-level WP-CLI configuration by default.
  • Added options to override this behavior globally or for individual commands.

• Documentation

  • Documented project configuration trust behavior and available override options.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

📝 Walkthrough

Walkthrough

Changes

Project configuration trust

Layer / File(s)	Summary
Configure and document project configuration trust src/Context/FeatureContext.php, README.md	Test processes now set WP_CLI_TRUST_PROJECT_CONFIG to an explicit environment value or default it to 1. The README documents global and per-command overrides.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Suggested reviewers: copilot, schlessera

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: enabling project configuration file trust during Behat runs.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/wp-cli-pr-6365-landing-slkyfp

---

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.}

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Context/FeatureContext.php	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@README.md`:
- Around line 150-157: Update the “Project configuration trust” heading in
README.md to use the repository’s configured setext heading style, and add a
gherkin language identifier to the command example’s fenced code block.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 47ae8d2e-65d6-4ffa-a607-d2c37a5e68b8

📥 Commits

Reviewing files that changed from the base of the PR and between b02c72d and 7896e5a.

📒 Files selected for processing (2)

• README.md
• src/Context/FeatureContext.php

[schlessera]

The change itself is right and minimal: get_process_env_variables() defaults WP_CLI_TRUST_PROJECT_CONFIG to 1 and an explicit outer value still wins, matching the existing pass-through pattern for WP_CLI_CONFIG_PATH and friends. '1' is accepted by normalise_trust_setting() in wp-cli/wp-cli#6365, and the per-command override in scenarios (WP_CLI_TRUST_PROJECT_CONFIG=false wp …) works because the process env is the base and the command prefix overrides it.

Two things before this can merge:

1. README code fence is not closed. At head, the gherkin block under "Project configuration trust" has an opening fence and no closing one (37 fences in the file, an odd count), so everything from "Setting up the tests in Travis CI" onwards renders inside a code block. Your own suggestion from 2026-09-03 has the closing fence; it just needs to be applied.
2. This only makes sense together with #6365. Once released, every Behat run in the org trusts project config by default, which is exactly the behaviour #6365 gates. If #6365 is deferred to 4.0.0, this should wait with it; if it goes into 3.0.0, the order is: merge this, tag wp-cli-tests 5.4.0, then #6365's CI can pass.

Not blocking: the codecov/patch failure is the two new lines in get_process_env_variables(), which has no unit coverage for any of its pass-throughs; the CodeRabbit heading-style nit is wrong, the sibling headings in that section are #### as well.