Resolve WP_VERSION to latest patch when only major.minor is provided

[Copilot]

WP_VERSION=5.1 would install exactly 5.1 even when 5.1.21 is available, causing failures in tests that assert against the latest patched behavior. Specifying an exact patch like 5.1.1 worked correctly, but omitting the patch component silently pinned to the unpatched initial release.

Changes

• bin/run-behat-tests: Added version resolution logic after the existing latest handling:
  • WP_VERSION=X.Y — fetches wp-versions.json from the artifacts branch and resolves to the highest available X.Y.Z patch release
  • WP_VERSION=X.Y.0 — normalized to X.Y (WordPress stores the initial release without a patch suffix)
  • WP_VERSION=X.Y.Z (Z > 0) — kept as-is
  • latest, trunk, nightly — unchanged
  • If the JSON fetch fails or no matching versions exist, WP_VERSION is left unchanged (graceful fallback)

# WP_VERSION=5.1  →  5.1.21 (latest patch for 5.1)
# WP_VERSION=5.1.0  →  5.1   (normalize: WordPress initial release has no .0 suffix)
# WP_VERSION=5.1.1  →  5.1.1 (exact, unchanged)

Version data is sourced from https://raw.githubusercontent.com/wp-cli/wp-cli-tests/artifacts/wp-versions.json (updated nightly via CI) to avoid hitting the WordPress API on every test run.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>WP_VERSION should default to latest patch if not provided</issue_title>
<issue_description>Right now, if you provide the version as WP_VERSION=5.1, it will pull in WP version 5.1, even if 5.1.1 is available. This causes issues in tests that rely on the latest WP version, like the checks in the wp-cli/doctor-command.

It would make more sense for the WP_VERSION to behave more closely like semantic versioning.

So, if 5.1.2 would be the latest available version:

• WP_VERSION=5.1 => "use latest patch verison for the 5.1 minor version" => installs 5.1.2
• WP_VERSION=5.1.1 => "use exact patch version 5.1.1" => installs 5.1.1
• WP_VERSION=5.1.0 => "use exact patch version 5.1.0" => installs 5.1 (as that is the equivalent to 5.1.0.

This effectively means that all the WP_VERSION=x.x requests will always include all security patches and hotfixes.</issue_description>

<agent_instructions>Implement an alternative to #207 that uses Bash only and lives entirely in bin/run-behat-tests.

It should fetch versions from https://raw.githubusercontent.com/wp-cli/wp-cli-tests/artifacts/wp-versions.json.

It should not implement strict semver check, but just be a bit smarter.

So, if 5.1.2 would be the latest available version:

• WP_VERSION=5.1 => "use latest patch verison for the 5.1 minor version" => installs 5.1.2
• WP_VERSION=5.1.1 => "use exact patch version 5.1.1" => installs 5.1.1
• WP_VERSION=5.1.0 => "use exact patch version 5.1.0" => installs 5.1 (as that is the equivalent to 5.1.0.

This effectively means that all the WP_VERSION=x.x requests will always include all security patches and hotfixes.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@thelovekesh @schlessera Can you please assign this task to me? @thelovekesh _As discussed today during hack day,_

To determine minor and patch versions we will need to rely on https://api.wordpress.org/core/stable-check/1.0/ to get the information on the released WordPress version, but as mentioned in wp-cli/core-command#108 (comment), this endpoint is not cached and result in slow responses or even rate limiting.

Since the wp-cli-tests package is widely used in CI for testing purposes, a high amount of calls to the API may cause rate limiting or worse API server might crash. To overcome this issue we will be saving version info as a JSON file in the repository itself which will be updated nightly using the GitHub actions workflow on the branch called artifacts.

cc/ @schlessera for visibility.</comment_new>
<comment_new>@thelovekesh

Tasks

• Add workflow to fetch WP version data and save them to the artifacts branch.
• Update version resolving logic to include latest patch release.</comment_new>
  <comment_new>@thelovekesh
  @schlessera Here is the PR to complete task 1 of above tasklist - Add wp-versions-data-fetcher workflow #199.</comment_new>

• Fixes WP_VERSION should default to latest patch if not provided #51

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gemini-code-assist]

Code Review

This pull request introduces logic to resolve WordPress versions specified as major.minor to the latest available patch release. The changes in bin/run-behat-tests are well-implemented, using curl and jq to handle version resolution from a remote JSON file. The logic appears correct and robustly handles various version formats and potential failure scenarios as described. I have one minor suggestion to improve the performance of the script.

[gemini-code-assist]

For a slight performance improvement and to avoid creating an extra process for echo, you can use a here-string (<<<) to pass the JSON content to jq. This is generally a more efficient way to feed a string to a command's standard input in Bash.

Suggested change

	RESOLVED_VERSION=$(echo "${WP_VERSIONS_JSON}" | jq -r --arg prefix "${WP_VERSION}." 'keys | map(select(startswith($prefix))) | sort_by(split(".") | map(tonumber)) | last // empty')
	RESOLVED_VERSION=$(jq -r --arg prefix "${WP_VERSION}." 'keys | map(select(startswith($prefix))) | sort_by(split(".") | map(tonumber)) | last // empty' <<< "${WP_VERSIONS_JSON}")