deps(deps): Bump k8s.io/api from 0.33.0 to 0.33.4 - #15
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [k8s.io/api](https://github.com/kubernetes/api) from 0.33.0 to 0.33.4. - [Commits](kubernetes/api@v0.33.0...v0.33.4) --- updated-dependencies: - dependency-name: k8s.io/api dependency-version: 0.33.4 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Author
AssigneesThe following users could not be added as assignees: Please fix the above issues or remove invalid values from |
dependabot
Bot
added
dependencies
Contributor
Author
|
Superseded by #20. |
sunib
added a commit
that referenced
this pull request
Jul 30, 2026
…pported, and one encoder for the mirror (#290) * docs(queue): strike the shipped attribution work and rank what it left The queue was built bottom-up: Tier 0 and Tier 1 are still unbuilt while the largest Tier 2 item shipped anyway, together with a consumer ask (#23) that was filed and fixed before it was ever ranked. Record that rather than smoothing it into a re-ranking. Struck: the fact stream, #23, the name tier, metrics Phase 1. Ranked in their place: the removal-wait decision (F then C, Tier 1, because a watched type the audit policy excludes is #15's failure mode one level down), the head-of-line block on the shard goroutine, the aggregated create, and the stream's two capacity questions. #5 loses one of its two arguments and says so: "audit cannot attribute a finalized delete at all" is false now that the sticky removal pointer does exactly that. The first argument — a hosted control plane will not give you an audit webhook — carries it alone. Also answers what "Event" meant in the inference deletion's open question: a real corev1.Event, which is not nearly free there because placement runs on the branch worker rather than in a controller, must attach to the GitTarget rather than to an object that may live in a remote cluster, and is a notification rather than a record. The durable half belongs to B2. * fix(analyzer)!: a refusal that can be fixed must not call itself unsupported Consumer ask #22, all three parts. Each one was a sentence, and each one was misleading a consumer that reads our source as the contract. ReasonRefusedStructural documented itself as "the permanent support boundary". It has not been permanent since Solvable shipped: the same code answers both ways, correctly, because a root refused for a configMapGenerator is nobody's to solve while one whose kustomization.yaml does not parse is one commit from adoptable. A consumer wrote Permanent = true off that sentence and shipped "this can never be synced" to the second author. The doc now points at Solvable. The refusal detail had one stem for both branches, so a solvable refusal read "kustomization uses unsupported feature(s): unparseable" — the opposite of what Solvable said beside it. The stem now comes from the same classification that sets Solvable, so the two cannot drift the way the doc comment did. The not-solvable stem is byte-identical to what it was, which is why the corpus baseline moves on exactly one refusal: the one that was lying. The nested-kustomization message shares that stem, and stops listing every construct it might have been in favour of the ones it found. Actor now states which scans can report which values. The ask asked whether a structure-only scan can name the platform operator; it cannot, and the reason is not the one reported. InScope gates only IssueOutOfScope; IssueUnresolvedKRM carries the same actor and is gated on a type registry that has seen a cluster. Cluster-awareness is the real gate, which is what makes the guarantee safe to state, and a corpus test pins it. BREAKING CHANGE: the refusal detail for a solvable render-root refusal and the message on an unsupported-kustomize issue are reworded. Both are documented as unstable strings; no code switches on them. * fix(git): one encoder for a create and an update, so the diff is one field Consumer ask #11, filed as cosmetic and accepted as not. A create serialized through sigs.k8s.io/yaml and an update through gopkg.in/yaml.v3, so sequences landed at the parent key's column in one and two columns deeper in the other, and the first update after a create rewrote every list line in the file to carry one changed field. For a product whose entire output is a Git diff, that is not ugliness, it is illegibility. Built in the order the queue asked for: a test pinning create and update output byte-for-byte first, then the fix wherever it failed. The direction was forced rather than chosen. yaml.v3 always indents a sequence under its mapping key, so the create style cannot be produced by the encoder that edits documents in place; create moved to yaml.v3. It is also what every file in a repository the operator has already updated once looks like. The fix is a package and not a shared constant: two encoders agreeing on an indent width are one refactor from diverging again, silently, because both emit valid YAML and nothing fails. internal/yamlstyle is the only place the write path constructs an encoder, and a source-scanning test refuses a second one. It also contains one behaviour difference that had to be absorbed: yaml.v3 raises "cannot marshal type" by panicking with a bare string, which escapes its own recover, where the JSON path returned an error. A write path that returns an error retries and reports; one that panics takes the process down. Adding a key still differs between the two paths, deliberately: a patch appends it where the document's own order puts it while a canonical render sorts keys, and preserving a human's key order is what the in-place editor is for. * docs(queue): strike #22 and #11, and record what building them taught Tier 0 and the one Tier 3 entry worth doing beside it are built, so they leave the queue. Both entries keep their argument and gain what the work found: #22's Actor answer was better than the doc line asked for — cluster-awareness is the gate, not AcceptancePolicy.InScope, and the second raise site the consumer's trace missed is the one that proves it. #11 records three things that only came out of doing it: the direction was forced by yaml.v3's sequence indentation rather than chosen, the fix had to be a package rather than a shared constant, and one panic-versus-error difference had to be absorbed at the seam.
8 tasks
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
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.
Bumps k8s.io/api from 0.33.0 to 0.33.4.
Commits
2daa873Update dependencies to v0.33.4 tagDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)