chore(gates): refresh the vendored manifest schema 2.25.0 → 2.26.0 - #602
Merged
Conversation
gate-22 and gate-53 validate every app manifest against THIS copy, not the one the app installs. It sat at 2.25.0, which has neither the 'flow' page type nor config.entitySource, so both flow-page migrations failed schema validation while passing their own repo's validator against node_modules. This is the fourth vendored copy of one schema found drifting this week. The refresh unblocks the migrations; it does not fix the drift, which needs the gate to read a pinned VERSION and fail loudly when an app declares a newer one.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The problem
gate-22(manifest-validation) andgate-53(effective-manifest-crossref) validate every app'ssrc/manifest.jsonagainst a copy of the manifest schema vendored here, not the copy the appinstalls from
@conduction/nextcloud-vue.That copy sat at 2.25.0. It has neither the
flowpage type norconfig.entitySource, both ofwhich landed in 2.26.0. So the two flow-page migrations fail both gates here while passing their own
repo's validator against
node_modules— the two validators disagree because they are readingdifferent schemas.
Blocked by this:
ConductionNL/dossiq#1402ConductionNL/openregister#2937The change
Refresh the vendored copy 2.25.0 → 2.26.0, taken from
nextcloud-vue@development.Strictly additive, so no manifest that passes today can start failing:
flowto the page-type enum (17 values, was 16)config.entitySourceandconfig.appVerified the old copy is a clean ancestor before overwriting — the only removals in the diff are the
versionline and one description string. No gate-local tightening was dropped.What this does not fix
This is the fourth vendored copy of this one schema found drifting this week. Refreshing is not
the fix. The gate reads a schema with a
versionfield and never compares it to anything, so driftis silent in the direction that matters: a manifest using a newer feature reads as invalid rather
than as newer than the gate.
The real fix is for the gate to fail loudly on that distinction — "manifest targets 2.26.0, gate has
2.25.0" is a different message from "invalid page type", and only one of them sends you to the right
repo. Filed separately rather than bundled here, because this PR is on the critical path for two
migrations.
Blast radius
quality.ymlis consumed as@main, so this takes effect fleet-wide on merge. Additive-only is whatmakes that safe.