You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[2026.3] Fix API tests for the untagged 2026.3 line - #537
Testing 2026.3 fails in the very first step
(run 35990112535):
Could not find package pimcore/skeleton with version ^2026.3.
01-setup-environment.sh maps any value not ending in .x to ^<version>, and composer create-project runs at stability stable. pimcore/skeleton has a 2026.3
branch but no v2026.3.0 tag, so nothing resolves.
The second failure mode is silent and worse: 02-install-pimcore.sh builds the same ^2026.3 but runs under minimum-stability: dev, where it does resolve — to 2026.x-dev, which normalizes to 2026.9999999.9999999 and outranks 2026.3.x-dev.
That would be a green run against the wrong line.
Change
Of the three schedule legs added in #513, only one is affected:
leg
before the tag
{ref: 2026.3, platform: 2026.3}
✗ ^2026.3 cannot resolve
{ref: 2026.3, platform: 2026.3.x}
✓ 2026.3.x-dev, the release branch
{ref: 2026.x, platform: 2026.x}
✓ 2026.x-dev
So the release leg is dropped until v2026.3.0 exists, and the 2026.3.x leg carries
the line meanwhile. The script defaults follow the same form (2026.3 → 2026.3.x),
the dispatch input description says which value applies when, and the release checklist
now states that step 1 is done at tagging time, not before — that is how it went for
2026.2 (#208 landed seven days after the tag).
Everything still reads 2026.3; nothing is reverted to an older line.
Why the release branch and not 2026.x
2026.x is also a valid stand-in for the unreleased line right now — its conflict
ranges are still open-ended (<2026.3) and tests/ is identical between the branches.
But 2026.3.x is strictly better: it exercises the release branch's pinnedconflict
bounds (<2026.3 || >=2026.4, #514), which is what will actually ship and which the 2026.x leg never touches.
At release
Re-add {"ref":"2026.3","platform":"2026.3"} to the schedule matrix once v2026.3.0 is
tagged, then forward-merge to 2026.x — schedule: only fires from the default branch.
Same sequence as #208.
Update Run locally command to use an available platform version
doc/04_API_Testing/01_API_TESTS.md:79
The primary “Run locally” command at line 24 still passes --platform-version=2026.3. Before the tag exists, that command triggers the exact skeleton-resolution failure documented here, so contributors following the main setup path will not reach this later guidance. Update that command to use 2026.x (or the tagged 2026.2) so the documented workflow is internally consistent.
Good catch on the missed Run locally command — fixed in c8ce501, it now passes --platform-version=2026.2. That was the last 2026.3 value in the doc outside the release checklist, where it is deliberate as the example of the next release.
The reason will be displayed to describe this comment to others. Learn more.
Copilot review overview
🔵 Needs a closer look
The documentation incorrectly implies that the open-ended dev line validates the release branch’s pinned dependency bounds.
Review effort: Balanced Findings: None
Previously missed (1)
In code that hasn't changed since last review
Nightly range does not prove exact release contents
doc/04_API_Testing/01_API_TESTS.md:79
<2026.N only establishes a lower bound; unlike the release branch's pinned <2026.N || >=2026.(N+1) ranges, it can accept later development versions. The PR description also calls the pinned conflict block explicitly unvalidated, so saying this installs “exactly” the release contents overstates what the nightly leg proves. Please document that this is representative only while the dev and release lines remain aligned and that pinned upper bounds still need release-time validation.
Fair point on the wording — "exactly" overstated it. Reworded in 7b52a17 and the two limits are now spelled out: the dev-line run is representative only while the dev line and the release branch are aligned, and it never exercises the release branch's pinned conflict bounds, which can only be validated once the pinned packages carry their own v2026.N.* tags.
The reason will be displayed to describe this comment to others. Learn more.
Copilot review overview
🔵 Needs a closer look
The description’s clean-forward-merge claim no longer matches the revised script defaults.
Review effort: Balanced Findings: None
Previously missed (1)
In code that hasn't changed since last review
Update PR description for changed default branch
.github/scripts/00-localsetup.sh:27
The PR description still calls these script changes a pure revert that leaves both branches identical, but 2026.x currently defaults to 2026.1 while this line now correctly defaults to 2026.2. That also invalidates the stated guarantee that the forward merge will stay clean; please update the description and merge plan to reflect the post-review change.
Correct — the description was stale after 91e66b1. Updated: the script defaults are now called out as a deliberate deviation from the revert rather than part of it, with the reason (step 2 of the release checklist was missed at the 2026.2 release, so 2026.x still says 2026.1) and what it means for the forward merge — it carries 2026.2 to 2026.x, which is intended, and conflicts with nothing since 2026.x has not touched those lines.
`^2026.3` cannot resolve before `v2026.3.0` is tagged: `composer create-project`
runs at stability `stable`, so the setup step aborts with "Could not find package
pimcore/skeleton with version ^2026.3". Under `minimum-stability: dev` the same
constraint does resolve, but to `2026.x-dev` — a green run against the wrong line.
Drops the `{ref: 2026.3, platform: 2026.3}` schedule leg until the tag exists; the
release branch stays covered by the `2026.3.x` leg, which also exercises its pinned
conflict bounds. Script defaults follow the same form, and the release checklist now
says to re-add the leg at tagging time.
The schedule matrix no longer offers a bare 2026.3, but workflow_dispatch
still did: platform_version was free text, and clearing it fell back to the
branch. Both paths produced `^2026.3` again.
Turns platform_version into a choice of the values that actually resolve, and
makes 01-setup-environment.sh say what to pass when a stable constraint fails.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Testing 2026.3 fails in the very first step
(run 35990112535):
01-setup-environment.shmaps any value not ending in.xto^<version>, andcomposer create-projectruns at stabilitystable.pimcore/skeletonhas a2026.3branch but no
v2026.3.0tag, so nothing resolves.The second failure mode is silent and worse:
02-install-pimcore.shbuilds the same^2026.3but runs underminimum-stability: dev, where it does resolve — to2026.x-dev, which normalizes to2026.9999999.9999999and outranks2026.3.x-dev.That would be a green run against the wrong line.
Change
Of the three schedule legs added in #513, only one is affected:
{ref: 2026.3, platform: 2026.3}^2026.3cannot resolve{ref: 2026.3, platform: 2026.3.x}2026.3.x-dev, the release branch{ref: 2026.x, platform: 2026.x}2026.x-devSo the release leg is dropped until
v2026.3.0exists, and the2026.3.xleg carriesthe line meanwhile. The script defaults follow the same form (
2026.3→2026.3.x),the dispatch input description says which value applies when, and the release checklist
now states that step 1 is done at tagging time, not before — that is how it went for
2026.2 (#208 landed seven days after the tag).
Everything still reads 2026.3; nothing is reverted to an older line.
Why the release branch and not
2026.x2026.xis also a valid stand-in for the unreleased line right now — itsconflictranges are still open-ended (
<2026.3) andtests/is identical between the branches.But
2026.3.xis strictly better: it exercises the release branch's pinnedconflictbounds (
<2026.3 || >=2026.4, #514), which is what will actually ship and which the2026.xleg never touches.At release
Re-add
{"ref":"2026.3","platform":"2026.3"}to the schedule matrix oncev2026.3.0istagged, then forward-merge to
2026.x—schedule:only fires from the default branch.Same sequence as #208.
Relates to pimcore/service-operations#1397.