Release: merge beta into main - #463
Merged
Merged
Conversation
…ed the E2E failures (#443) DELIBERATE EXPERIMENT, and revertible in one commit. CI bisected launchpad's 11 E2E failures to the 9.9.0 -> 9.11.0 move: f93f767 9.11.0 E2E failure d158755 9.9.0 E2E success (the pin) But an isolated reproduction contradicts it. Running the same specs against a launchpad-demo instance on :8605, seeded exactly as CI seeds (tests/e2e/seed.sh: e2e-grantee, recipient, firstrunwizard disabled, demo-data skipped), with a local build against 9.11: conditional-visibility-editor.spec.ts 13 passed <- the 7 CI failures do NOT reproduce dashboard-sharing.spec.ts 4 failed <- but at line 83, on the switcher row, NOT on CI's .sharee-option So two runs correlate the version with the failure, and a controlled run says 9.11 passes those tests. Correlation across two CI runs is not causation, and the difference may be load rather than version. This puts 9.11 back so CI can answer it: the 7 recur -> the NcSelect rework really is the cause, and the specs get adapted to the new component the 7 pass -> they were load-flakes, the pin was incidental, and the other ten apps on 9.11 need nothing Either answer is worth more than shipping a pin whose justification does not survive a controlled test. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
#446) The experiment in #443 has its answer, and it is the one that keeps the pin: E2E on 9.11 failed with the SAME ELEVEN tests and the SAME signatures as before. 127 passed, 11 failed 7x conditional-visibility-editor waiting for '.vs__dropdown-option' 4x dashboard-sharing waiting for '.sharee-option' That is deterministic, not load. Two independent CI runs on 9.11 produce an identical failure set, and 9.9.0 produces none, so the NcSelect rework is the cause. My isolated reproduction said otherwise -- those same specs passed on a 9.11 build against a seeded launchpad-demo -- and I have not yet found what differs between that environment and CI. That gap is real and worth closing before the specs are adapted, because adapting them against an environment that does not reproduce the failure fixes nothing. So development goes back to green on the pin while that work happens, rather than sitting red. The adaptation is still the plan; this is not a retreat from it. The one adaptation already understood and shipped separately is stackiq's (#841): 9.10 turned .vs__search from the <input> into a wrapper div around it, measured on a live build. launchpad's two failure modes are different and not yet explained. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…260830153148 chore(sync): carry beta back into development
Adapts to @nextcloud/vue 9.11 rather than pinning away from it, and
takes the pin off.
The eleven E2E failures were never an unstable element. The Playwright
trace from CI says so directly:
- locator resolved to <li class="vs__dropdown-option">
- attempting click action
- element is visible, enabled and stable <- stable
- scrolling into view if needed
- <div class="visibility-rule-row__actions"> ... intercepts
The option was VISIBLE, ENABLED AND STABLE. The click was intercepted by
the element painted on top of it.
Both failing areas are the same shape. A column of blocks; a select in
one of them; its dropdown opens downward over the LATER siblings; those
siblings have no stacking context, so they paint last and win:
conditional-visibility <div class="visibility-rule-row__actions">
dashboard-sharing <div class="dashboard-config__field ...public">
<p class="dashboard-config__hint">
9.10's floating-label rework (#8570) is what made it reachable: the
control got taller, so the dropdown now extends far enough to reach them.
That is why 9.9.0 was green and 9.11 is not, without either version being
broken.
The fix is a stacking context on the block that holds the select, in both
places. Nothing else changes, and the dropdown is only raised where a
select actually lives.
⚠️ This could not be verified locally. The same specs PASS against a
seeded launchpad-demo on :8605 built with 9.11 -- the layout there does
not put the dropdown over those siblings. The trace from CI is the
evidence this rests on, and CI is where it has to be confirmed.
Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…e modal mask (#452) The stacking fix in #450 was built on the trace and was not enough. E2E on 9.11 with it merged is still 127 passed / 11 failed, the same eleven. The second trace names a bigger interceptor than the first one did: 70x class="modal-mask" 24x class="checkbox-content__text checkbox-radio-switch__text" 20x class="dashboard-config__hint" 18x class="visibility-rule-row__actions" 8x class="dashboard-config__field dashboard-config__public" is Nextcloud's own modal backdrop, and it dominates. A z-index inside the modal cannot lift the dropdown above the mask if the dropdown is no longer INSIDE the modal: 9.10's NcSelect appears to render its menu outside the dialog (appended/teleported), which puts it beneath the backdrop in stacking order. That is a different defect from the one #450 addressed, and it needs the menu kept in place or lifted above the mask -- not more per-component z-index. The CSS from #450 is KEPT. Those three smaller interceptors are real, the rule is documented against its trace, and it is inert while the dropdown renders inline on 9.9.0. So the pin goes back while that is worked out, because leaving development red to hold a position is not a trade worth making. This is not a decision that 9.11 is unusable -- it is a decision not to sit red while the portal behaviour is understood. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…#454) EXPERIMENT. Reverted in one commit if CI stays red. A real difference between the two versions, verified in the published packages: 9.9.0 --vs-dropdown-z-index: 9999 declared on body 9.11.0 --vs-dropdown-z-index: 9999 declared on .nc-select.v-select.select NcSelect renders its menu with appendToBody: true in BOTH versions -- so the menu is a child of <body> and is NOT a descendant of the select root. A custom property declared on the root therefore cannot reach it, while one declared on body can. That is a plausible mechanism for the modal-mask interception the trace shows, and it is the only substantive CSS difference I found between the versions. WHAT I HAVE NOT SHOWN is that it is the cause. Probing a live 9.11 build on an isolated instance: with the rule: body --vs-dropdown-z-index=9999, menu z-index=100001 without the rule: body --vs-dropdown-z-index=9999, menu z-index=100001 Identical. Something else already declares the variable on body there, so that environment cannot tell the two states apart -- and it is the same environment that fails to reproduce the 11 failures at all. The probe is not evidence for the fix; it is evidence that the probe cannot judge it. CI is the only place the failure reproduces, so CI is where this gets judged. The rule is harmless either way: identical value, and inert once upstream fixes the scope. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
…74027 chore(sync): carry main back into beta
…260830174035 chore(sync): carry beta back into development
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The 1.0.20 release bumped the version on main. Without this, development stays behind main and the next development -> main promotion conflicts on the version file. Version files resolve to development's side, which is the higher line, so this never moves a version backwards.
…0.20 chore(release): sync main back into development
…468) Dependabot re-proposes these on every run, and each one takes `npm ci` or `npm run build` from green to red with no code change in this repository that can fix it. Closing the pull requests does nothing: without an ignore rule they come straight back. Each is blocked by a package we do not control, verified against the registry rather than assumed: - typescript 7 typescript-eslint hard-throws on TS >= 7 (a `versionMajor >= 7` guard in its dist/index.js) and every published version still peers `typescript: ">=4.8.4 <6.1.0"`. - webpack-cli 7 @nextcloud/webpack-vue-config 7.0.4, the LATEST, peers `webpack-cli: ^6.0.1`. - @babel/core 8 the same package peers `@babel/core: ^7.22.9`. - @babel/preset-env preset-env 8 requires core 8, so the pair moves together or not at all. Splitting them is what broke filinq. These are COMPATIBILITY limits, not security ones. `npm audit` reports no advisory against any version pinned here, so holding them costs no exposure. Lift each the moment its blocker ships support. Deliberately NOT held: stylelint 17, vitest 4 and pinia 4. All three were blocked earlier today and all three are now adoptable, so dependabot should keep proposing them. Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Release: merge development into beta
rubenvdlinde
requested review from
Rem-Dam,
SudoThijn,
WilcoLouwerse,
bbrands02,
remko48 and
rjzondervan
as code owners
August 30, 2026 18:43
Contributor
Quality Report — ConductionNL/launchpad @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| format | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| composer | ✅ | ✅ 104/104 | |||
| npm | ✅ | ✅ 526/526 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ✅ | ||||
| Playwright | ❌ | ||||
| Hydra gates | ❌ |
Quality workflow — 2026-08-30 19:09 UTC
Download the full PDF report from the workflow artifacts.
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.
Stable promotion.
betaholds 2 commit(s)maindoes not.App signing is known-broken on part of the fleet and is being fixed separately; a failure whose only red is the release/signing step is waived here by explicit decision, so the merge lands but no artifact publishes until the secret is valid.