chore(deps): bump the talos group across 1 directory with 3 updates - #6826
chore(deps): bump the talos group across 1 directory with 3 updates#6826dependabot[bot] wants to merge 2 commits into
Conversation
![ksail-bot[bot]](https://avatars.githubusercontent.com/in/2880167?s=60&v=4){kind=small}
✅MegaLinter analysis: Success✅ Linters with no issuesactionlint, bash-exec, git_diff, hadolint, jscpd, jsonlint, lychee, markdown-table-formatter, markdownlint, prettier, prettier, shellcheck, shfmt, stylelint, syft, trivy-sbom, trufflehog, v8r, v8r, yamllint Notices
See detailed reports in MegaLinter artifacts
|
Parked on a named, live-verified blocker — not actionable here, and closing it does not help. This PR bumps the Talos group This is NOT the grouped-update/desktop-module cause (#6816). On this head Closing it is ineffective — measured today. #6813 was closed as a stalled talos-group PR at Blocker: loft-sh/apiserver — needs a revision built against Kubernetes 0.37 apiserver | last-verified 2026-09-01: not shipped. Newest published revision is still v0.0.0-20260707184419-aef558a5ae8d, pinning the 0.36 apiserver. Leaving this open and parked rather than closing it. It should go green on its own once #6776 lands. |
This PR has been @dependabot rebase |
|
Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry! If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request |
Same root cause as #6830: Dependabot cannot rebase because This head is both @dependabot recreate |
dependabot
Bot
changed the title
200115a to
b4ef2a4
Compare
Named cause, replacing "38 failing checks against a stale base". The rebuild cleared the conflict (
|
Correction to my comment above. I wrote that The Everything else is unchanged: the conflict is cleared, this PR should not be closed, and a manual |
Diagnosed. This PR's red CI is not the Dependabot rebase forfeiture — it is a breaking API change in the bump itself, and it needs a code adaptation before it can go green. CI is complete at
Not a pre-release-exclusion problem. The obvious-looking remedy is to stop bumping into pre-releases, and that would be wrong here: Two things follow.
The remaining work is a genuine adaptation to the new |
Correction to my comment above, and this PR's terminal state: parked on #6728. I wrote that this PR "needs a code adaptation before it can go green". That is necessary but not sufficient, and acting on it alone would have burned a run for nothing. Adapting the three Evidence — local build at the merged head. I merged
Why cluster 3 is the real blocker.
So there is no version to bump to on either side of the vcluster path. This is the standing ceiling #6728 documents, which already states it directly: "Adapting our own code is not the missing piece … the blocker is strictly the Control: Blocker: loft-sh/apiserver k8s-0.37-compatible release | last-verified 2026-09-01: not shipped ( Disposition. Parked, not closed — closing recreates it under a new number (#6813 → #6826) and cannot fix a compile break. Left un-rebased deliberately: pushing the merge would spend a full 77-check CI cycle on a PR that provably cannot pass. The three call-site migrations land with whichever Talos bump clears #6728, per that issue's acceptance criteria. |
Blocker: #6728 | last-verified 2026-09-02: still OPEN — not shipped Re-verified live this run rather than inherited from the previous park record. This PR stays Recording why it is not automation-owned, so a later run does not re-derive it: the branch is Next action belongs to #6728, not here. |
Pull request was converted to draft
This PR cannot finish itself, so I am requesting a regeneration rather than leaving it to age. Why it is stalled (verified 2026-09-06):
Why regenerate rather than repair in place: this PR targets release candidates that GA has already superseded. Resolved from the Go module proxy:
A recreate re-resolves onto the released versions and rebases off the conflict. Expect CI to stay red after this regenerates, for a reason that is not this PR's fault: @dependabot recreate |
Retracting the I posted that request without first reading the 2026-09-06T12:26Z parking note above it, and my diagnosis was incomplete. Correcting the record: What I got wrong. I attributed the red CI to the which breaks Why a recreate cannot help. KSail embeds both Talos and the vcluster stack. Talos ≥ Standing state, unchanged: Blocker: loft-sh/apiserver k8s-0.37-compatible release | upstream | last-verified 2026-09-05: not shipped Compatibility work is tracked in #6728; the Talos call-site migration in #6776. If dependabot honours the retracted command before it sees this, the regenerated head will fail the same way and should simply be re-parked here rather than re-diagnosed. I also filed #6915 on this before reading the existing analysis; it duplicates #6728 and #6776 and I am closing it as such. |
7673160 to
9847a5c
Compare
Outcome of the retracted Dependabot acted at 14:02:29Z, before my retraction landed. The regenerated head is It did not pick up the GA releases — The practical consequence for future ticks: Standing state is unchanged: Blocker: loft-sh/apiserver k8s-0.37-compatible release | upstream | last-verified 2026-09-05: not shipped Compatibility in #6728, Talos call-site migration in #6776. Re-park at the new head rather than re-diagnosing it. |
9847a5c to
4284bdb
Compare
Diagnosed: this is a source-incompatible Talos machinery bump, not a flakeAn earlier run left this undiagnosed because Root causeAll 39 failures cascade from Alongside it, transitive Kubernetes API breaks surface in the build graph:
So this is one source-incompatible upgrade with a second, indirect k8s-API break riding along in the What this means for ownershipDependency automation cannot finish this head: it needs source changes in this repository Not attempted in this run, and deliberately so: I did not want to push a half-finished migration
|
Correcting my previous comment — this is already diagnosed, and it is not a migration to attemptMy comment above called this "undiagnosed" and framed the fix as adapting our source off the removed #6728 already holds the full chain, and it
So the What survives from my earlier comment is only the method, which I still think is worth recording:
That is how I read this build at all. But having read it, I should have checked for an existing Corrected status: this PR is parked on #6728, |
Diagnosis — this is a breaking API change, not a flaky buildThe 39 failing checks are one failure cascading: Primary cause — Talos machinery removed Three call sites need adapting to the new machinery API. That is real work, and it is ours — a breaking bump changes the work, not who owns it. Secondary cause — the bump drags in Worth flagging: What this needsNot a re-run and not a rebase. It needs the three |
Follow-up to my own diagnosis above: the canonical blocker for this root cause already exists. Blocker: #6728 | upstream | last-verified 2026-09-08: still OPEN ( Its title states the same conflict I reached from the compiler errors: "Talos beta.1 needs k8s 0.37 while the vcluster stack pins 0.36". So the The |
4284bdb to
634c83a
Compare
Parked on two named, live-verified blockers. Diagnosed so the next run does not repeat this. This PR cannot self-progress: auto-merge has been armed since 2026-09-06, but an arm cannot carry a failed required check, and The build reports three independent breaks, and only the third is new information:
Two notes worth keeping, because both are easy to get wrong from the outside:
Sequencing: #6728 first, then #6962, both as adaptation commits on this branch — #6962 cannot land on Leaving the arm in place meanwhile: it is harmless while a required check is red, and re-arming later is a step someone would have to remember. |
634c83a to
c2e538d
Compare
Bumps the talos group with 2 updates in the / directory: [github.com/siderolabs/talos](https://github.com/siderolabs/talos) and [github.com/siderolabs/omni/client](https://github.com/siderolabs/omni). Updates `github.com/siderolabs/talos` from 1.14.0-alpha.2 to 1.14.0-rc.2 - [Release notes](https://github.com/siderolabs/talos/releases) - [Changelog](https://github.com/siderolabs/talos/blob/main/RELEASE.md) - [Commits](siderolabs/talos@v1.14.0-alpha.2...v1.14.0-rc.2) Updates `github.com/siderolabs/talos/pkg/machinery` from 1.14.0-alpha.2 to 1.14.0-rc.2 - [Release notes](https://github.com/siderolabs/talos/releases) - [Changelog](https://github.com/siderolabs/talos/blob/main/RELEASE.md) - [Commits](siderolabs/talos@v1.14.0-alpha.2...v1.14.0-rc.2) Updates `github.com/siderolabs/omni/client` from 1.9.1 to 1.10.5 - [Release notes](https://github.com/siderolabs/omni/releases) - [Commits](siderolabs/omni@v1.9.1...v1.10.5) --- updated-dependencies: - dependency-name: github.com/siderolabs/omni/client dependency-version: 1.10.5 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: talos - dependency-name: github.com/siderolabs/talos dependency-version: 1.14.0-rc.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: talos - dependency-name: github.com/siderolabs/talos/pkg/machinery dependency-version: 1.14.0-rc.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: talos ... Signed-off-by: dependabot[bot] <support@github.com>
c2e538d to
97de21f
Compare
@dependabot rebase |
|
Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry! If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request |
Blocker: #6728 | upstream | last-verified 2026-09-12: not shipped — Re-verified live this run, not inherited from the previous record (which had gone 4 days stale). Park stands. Not re-running or re-queuing. One note carried over from #6845, since this PR shares its state: the 39 red checks here ran on Auto-merge is armed on this PR and cannot fire while the branch is red and |
1 participant
Bumps the talos group with 2 updates in the / directory: github.com/siderolabs/talos and github.com/siderolabs/omni/client.
Updates
github.com/siderolabs/talosfrom 1.14.0-alpha.2 to 1.14.0-rc.2Release notes
Sourced from github.com/siderolabs/talos's releases.
... (truncated)
Commits
414a1d4release(v1.14.0-rc.2): prepare releasea740329feat: bump kernel, containerd and go0048cd3chore: bump vulncheck datesacc89cbfix: use default terminal theme colors in talosctl dashboardd78c61cfix: don't create new client in dry-run mode7276d54fix: preserve selected sd-boot entry on upgrade68a4366fix: use the UKI command line when the config has no install sectione32a266fix: persist in-memory meta on fresh install35c8f17fix: drop lockdown=confidentiality default for 1.14+9771995fix: reduce stalls in the etcd member promotion cycleUpdates
github.com/siderolabs/talos/pkg/machineryfrom 1.14.0-alpha.2 to 1.14.0-rc.2Release notes
Sourced from github.com/siderolabs/talos/pkg/machinery's releases.
... (truncated)
Commits
414a1d4release(v1.14.0-rc.2): prepare releasea740329feat: bump kernel, containerd and go0048cd3chore: bump vulncheck datesacc89cbfix: use default terminal theme colors in talosctl dashboardd78c61cfix: don't create new client in dry-run mode7276d54fix: preserve selected sd-boot entry on upgrade68a4366fix: use the UKI command line when the config has no install sectione32a266fix: persist in-memory meta on fresh install35c8f17fix: drop lockdown=confidentiality default for 1.14+9771995fix: reduce stalls in the etcd member promotion cycleUpdates
github.com/siderolabs/omni/clientfrom 1.9.1 to 1.10.5Release notes
Sourced from github.com/siderolabs/omni/client's releases.
... (truncated)
Commits
3da5140release(v1.10.5): prepare release0f61f97test: fix talemu version to v1.0.0-6-g9326528f3e43cffix: provide machine id consistently in provision API logs51470e0fix: add missing timeout to the version API call in the identity taskf745553fix: change incorrect version contract for kubespan6c09850fix: stop a link to an exposed service from starting a login flow1029e9cfeat(frontend): add filename param to image downloadsb49f605fix(frontend): fix etcd backup interval not editable615998arelease(v1.10.4): prepare releasebc586e4feat: allow listing and deleting the Kubernetes token signing keys