Conversation
|
Server docker: perconalab/pmm-server-fb:PR-4571-9b5d1f7 |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7402/ |
PMM-15347-bootstrap-abort-per-member alone lacks percona/pmm#5888's startup-sync fix (open on PMM-15360-om-service-gate, a separate, currently-unmerged chain) - pmm-managed's periodic OM sweep never picks up PMM's own switch state until enable/disable is toggled again after a restart. PMM-15347-om-bootstrap-fb merges both chains fresh onto their shared base and carries the fix.
PMM-15347-om-bootstrap-fb on percona/pmm just gained PMM-15316's SEP secrets hardening (cherry-picked from the unmerged PMM-15205-sep-fb line), cherry-picked after this PR's pin already resolved the branch's prior tip. Empty commit so Jenkins re-fetches the dependency fresh.
|
Server docker: perconalab/pmm-server-fb:PR-4571-7d9f12a |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7413/ |
|
Server docker: perconalab/pmm-server-fb:PR-4571-a08488b |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7414/ |
|
FB run 35242727872 went red on a single leg — the Playwright I re-ran the failed job on this run and it came back green, and the run as a whole is now green (attempt 2, 54 success / 3 skipped, 0 red) — so your change isn't implicated and your PR is clear. PMM-QA is tracking the stability of that setup step; the exporter is launched through a detached Generated by Claude Code |
Points the pmm dependency at PMM-15347-om-integration-v3 instead of PMM-15347-om-bootstrap-fb. The two were the same kind of thing - a no-PR bundle of the OM branches, merged by hand so one image can carry work that is still split across several pull requests - so keeping both meant rebuilding both every time any chain moved. Only one of them was, and it was not this one: PMM-15347-om-bootstrap-fb still sat at 211389ed4, on the baseline as it stood before 2026-09-23, leaving it 551 files behind and carrying neither #5949's retry of a refused inventory refresh nor #5995. PMM-15347-om-integration-v3 carries every commit of all eight open OM PRs - #5866, #5853, #5888, #5921, #5995, #5949, #5950, #5951 - checked commit by commit rather than by branch tip, since the chain above #5949 was rebased today. It is force-pushed on every restack, by design, so a rebuild takes whatever it points to at that moment. The build's own sha is the record of what an image actually contains.
|
Server docker: perconalab/pmm-server-fb:PR-4571-2b16f10 |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7496/ |
No dependency change: the pmm dep already points at
PMM-15347-om-integration-v3. This records what that branch now holds and
triggers the build, since the branch moved under it.
Bundle 53041711e -> 55955bb96, both fixes found by running the previous
image rather than by review:
#5949 A scoped inventory refresh the app refused with a 409 was
attempted once and dropped, but the same pass marks the run
registered and takes it out of the stepper's sweep, so there was
no next tick to retry on. A run finishing while an estate sweep
held its hosts therefore waited out the app's whole schedule
before its services appeared.
#5888 applyOMSwitch triggered a topology collection and only then told
SEP the feature was on. om_inventory refuses a sweep while its
own ENABLED is false, so the one collection meant to fill the
estate on enable was refused every single time, recorded SKIPPED
with "OM Inventory is switched off".
All eight OM PRs are green and the bundle carries every one of their 41
commits, checked per commit after today's restack.
|
Server docker: perconalab/pmm-server-fb:PR-4571-b0634ff |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7501/ |
…name The pmm dep branch PMM-15347-om-integration-v3 was force-pushed after the whole OM stack was rebased onto main at/after #5992, so this build carries: - main's SEP -> PMM Extensions rename, which means the server now provisions the pmm_extensions role and database and proxies location /extensions/ rather than sep/sep and /sep/; - the stack's own half of that rename, which #5992 could not reach because it was added on an unmerged branch: --extensions-url and --extensions-token with their PMM_EXTENSIONS_* envars, plus the internal identifiers and the om plugin's package name. The side-car paired with this image therefore has to be a post-rename build. The pre-rename pairing (PR-4571-b0634ff with sep:omfix-*) will not work against it in either direction: the role names and the nginx prefix both moved.
Build 6 failed before compiling anything. The cause was in the bundle,
not in Jenkins: ui/pnpm-lock.yaml had package and snapshot entries
sitting inside the importers section, so a real install walked an
importer dep with no version and died in parseDepRefs:
[ERROR] Cannot read properties of undefined (reading 'startsWith')
at parseDepRefs / toImporterDepPaths / filterLockfileByImportersAndEngine
It came from resolving the lockfile conflict by hand during the rebase.
The conflicting commit's additions were lifted with `git show | grep
'^+'`, which concatenates additions from every section of the file into
one blob; that blob was inserted at a single point inside `importers:`.
`pnpm install --lockfile-only` did not catch it -- resolution succeeded
and the om entries it needed were all present and correct. Only a
headless `--frozen-lockfile` install walks the importer snapshots, which
is what CI runs and what now reproduces green locally on a clean tree.
The lockfile is pnpm's own output rather than a repaired hand edit. That
carries one unrelated change with it: @vitejs/plugin-react floats 6.1.0
-> 6.1.1, which re-resolving a `^6.1.0` spec picks up.
Build 7 would have failed compiling the UI. ui/apps/pmm/src/router.tsx
imported AtwApp and SchemaDrivenPlugin twice:
src/router.tsx(23,10): error TS2300: Duplicate identifier 'AtwApp'.
src/router.tsx(24,10): error TS2300: Duplicate identifier 'SchemaDrivenPlugin'.
Same origin as the lockfile damage in the previous rebuild: resolving
the rebase's conflicts. main had renamed those two imports to
@pmm-extensions/*, and our side of the hunk both renamed them and added
OmApp and OmPage beside them. The resolver kept main's lines and then
appended ours whole, so the two shared imports landed twice.
Caught by running the UI build rather than by review, which is also why
this rebuild adds it to the checks: `pnpm install --frozen-lockfile`
(what missed the lockfile corruption) and `tsc --noEmit` (what missed
this) both now pass on a clean tree, alongside go build.
An audit for the same shape across every TypeScript file the stack
touches found this one file and no others.
|
Server docker: perconalab/pmm-server-fb:PR-4571-3c88545 |
|
API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7533/ |
This branch has not been deployed
3 participants
Pins the main dependency at PMM-15347-bootstrap-abort-per-member, the tip of the
stacked PR chain that drives MongoDB bootstrap from pmm-managed (#5949), adds the
bootstrap UI to Hosts/Operations (#5950), and adds abort + per-member settings
(#5951).
No url override: the branch is on percona/pmm, which is what .gitmodules already
gives this dependency.
Paired at run time with the SEP side-car image built from percona/SEP's
PMM-15347-om-integration (carries the matching om_bootstrap app, now activated in
sidecar/settings.yaml).
https://jira.percona.com/browse/PMM-15347