[Adi-ty]

What this PR does

Lets callers test against the newest WordPress release or the development version without knowing a version number. ci-test-php.yml (and through it, wp-versions in wp-ci.yml) now accepts latest and trunk as wp-version, and ci-test-build-artifact.yml accepts trunk in addition to its existing latest.

Closes

Part of #51

Changes

• ci-test-php.yml: latest boots https://wordpress.org/latest.zip and trunk boots WordPress/WordPress#master. The mirror has no trunk branch; master is trunk. Every other value is still WordPress/WordPress#<value>, and an empty value still falls back to .wp-env.json. latest can't be passed to wp-env as an empty value, because wp-env would then use .wp-env.json, which may pin an older version.
• ci-test-build-artifact.yml: trunk writes core: "WordPress/WordPress#master" to the generated override, and latest stays core: null. With trunk, wp doctor's core-verify-checksums check is skipped, because WordPress.org publishes no checksums for development builds.
• The wp-version and wp-versions descriptions list the aliases, and note that x.y.0 releases are tagged x.y: there is no 6.8.0 tag.

How I verified

$ pipx run yamllint .
./.github/workflows/ci-lint-php.yml
  23:201    warning  line too long (334 > 200 characters)  (line-length)   # already on main
$ actionlint .github/workflows/*.yml examples/*.yml
$ bin/check-workflows.sh
Workflow/example contract check passed.

I ran byte-identical copies of both workflows in a private test repo on ubuntu-latest (@wordpress/env 10.39.0 for ci-test-php, the latest version for ci-test-build-artifact). Every job passed. Each job read the booted version back with wp core version:

Workflow	wp-version	wp-env core	Booted
ci-test-php	latest	https://wordpress.org/latest.zip	7.1.4 in cli and tests-cli
ci-test-php	trunk	WordPress/WordPress#master	7.2-beta4-65303 in cli and tests-cli
ci-test-php	6.8	WordPress/WordPress#6.8	6.8 (unchanged)
ci-test-php	empty	from .wp-env.json	7.1.4 (unchanged)
ci-test-php, use-wp-env: false	latest	not set	wp-env not used
ci-test-build-artifact	latest	null	7.1.4; wp core check-update: at the latest version
ci-test-build-artifact	trunk	WordPress/WordPress#master	7.2-beta4-65303; wp doctor passed with core-verify-checksums skipped
ci-test-build-artifact	6.8	WordPress/WordPress#6.8	6.8

Acceptance criteria

Runtime behavior

• wp-version: latest boots the newest stable release in ci-test-php
• wp-version: trunk boots the development version in ci-test-php and ci-test-build-artifact
• Existing values (a version tag, or empty) behave as before
• trunk passes ci-test-build-artifact's wp doctor gate

Code quality

• Lint: only the pre-existing long line on ci-lint-php.yml line 23
• Static analysis: actionlint is clean
• Tests: bin/check-workflows.sh passes

Housekeeping

• PR title is a Conventional Commit
• examples/ unchanged: no input changes
• yamllint, actionlint and bin/check-workflows.sh pass locally

Reviewer notes

• latest reaches wp-env differently in the two workflows. ci-test-php sets the WP_ENV_CORE environment variable, which has no way to ask for wp-env's own latest-version lookup, so it passes latest.zip. ci-test-build-artifact writes core: null and wp-env looks the version up itself. Both boot the same release.
• Values are lowercase, as documented. GitHub expressions ignore case, so ci-test-php also accepts Latest. In ci-test-build-artifact a mixed-case value fails at wp-env start, as Latest already did.
• latest and trunk move over time. wp-env only re-downloads core when its config changes or when you pass --update. That's fine today, because GitHub-hosted runners and ARC pods start each job with an empty ~/.wp-env. Revisit this if the wp-env work for [wp-ci] Close the adoption gaps for consuming projects #51 caches ~/.wp-env. ci-test-build-artifact already passes --update.
• Already on main, not changed here: in ci-test-build-artifact, wp doctor's core-update check fails any pinned version behind its newest patch release, such as 6.8.

---

_{Conventions: AGENTS.md · PR process: CONTRIBUTING.md}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.