⬆️ Bump golang.org/x/net from 0.53.0 to 0.55.0 - #5
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
dependabot
Bot
added
dependencies
jmle
pushed a commit
that referenced
this pull request
Aug 27, 2026
…yor#157) Implements ADR 0015 and the rules half of ADR 0014. Skills move to the AgentSkills.io format packaged as an ordinary OCI image, and a `skill-loader` init container assembles `/opt/skills` from image, git and inline sources alike. Rules stop being a field nothing reads and start reaching the model. Closes konveyor#151. Refs konveyor#152. It keeps three items: the `ContextWindow` budget check, the repo-shadowing log, and the audit of cards authored while the harness still concatenated everything. Refs konveyor#126, out-of-box skills OCI image. Its "done when" now holds: the default skills image builds in CI and a run consumes it out of the box, verified on a cluster. Left open rather than closed because it also asks for the Java to Quarkus sample workflow content, which is konveyor#123 and is not here. Close it if you read the acceptance criterion as met. Refs konveyor#31, SkillCollection child SkillCard creation. The mechanism it asks for exists now, including owner references and garbage collection, but only for image sources; the git half is the one thing left, and konveyor#153 carries it. Worth deciding whether konveyor#31 stays or folds into konveyor#153, since they now overlap. Refs konveyor#81, documentation for building skill card images. Not written here, but what it needs to document changed: a skill image is now an ordinary Containerfile build rather than a skillctl invocation. Refs #5 and #1. Their remaining Phase 3 items are konveyor#29, konveyor#30 and konveyor#31; this lands konveyor#29 and konveyor#30, leaving konveyor#31. Refs konveyor#147, which asks for one skill bundle image built from a Containerfile with skillctl dropped. That part is here. The release-tools tagged pipeline is not. Refs konveyor#154 and konveyor#155. Neither is done, but both stop being hypothetical with this: `spec.source` is a real clone now, and dropping skillctl is what removes the media type konveyor#155 is about. Supersedes the approach in konveyor#44, which asked for `skill.yaml` metadata and `skillctl build/push`. ADR 0015 reverses that, for the reasons in its context section. konveyor#44 is already closed; noting it so the reversal is not a surprise to anyone who reads it first. ## Reviewing this It is large, so the commits are the unit of review. Each builds and tests on its own, in order: | | commit | what to look at | |---|---|---| | 1 | `Ignore .dev/` | trivial | | 2 | `Add api/skill` | the shared validator, and that it is stricter than both copies it replaces | | 3 | `Widen SkillCard and SkillCollection` | the CRD surface: `subPath`, `ref`, `deliveryMode` | | 4 | `Assemble the skills root` | the loader: shape detection, containment in `copyTree`, failure modes | | 5 | `Inject always-loaded rules` | ADR 0014's deliverable, and prompt layer ordering | | 6 | `Package skills as an ordinary OCI image` | the Containerfile and what skillctl removal costs | | 7 | `Stage skill sources and run the loader` | `resolveSkillVolumes`, dedup and the traversal guard | | 8 | `Enumerate a SkillCollection image` | the Job, its RBAC, and the trust boundary marked in `materialize.go` | | 9 | `Reconcile ADRs 0014 and 0015` | docs only | | 10 | `Add the skill probe rig` | pod-shape probes | | 11 | `Probe the controller and a live model` | the controller and live-model probes | | 12 | `Run the skill delivery checks in e2e instead of by hand` | 10 and 11 folded into CI, and deleted | | 13 | `Check that a rule reaches the model, without a live model` | the request recorder and the tool call | Commits 4 and 5 are the seam worth understanding: the loader *produces* the manifest recording which skills are rules, and the harness *consumes* it. That split is why the controller never needs to know a skill's frontmatter name. ## What was verified, and how to re-verify it envtest has no kubelet, so nothing about ImageVolumes, init containers or a pod that either starts or does not is reachable from `make test`. All of it runs in e2e now, on a cluster built fresh for every change. It used to be scripts under `hack/skill-probe/` that somebody had to remember to run, and that is how they failed us: the enumeration probe passed for days against a `skill-enumerator` ServiceAccount left in a namespace by hand, while the code that should have created it did not exist. `hack/run-e2e-skills.sh`, in the existing e2e job, each scenario in a namespace nothing else has touched: - An image bundle enumerates into one SkillCard per skill, each carrying the `subPath` it was found at rather than one somebody typed - The enumerator's ServiceAccount and RoleBinding exist in the collection's namespace, not the operator's - Pointing the collection at a smaller image prunes the cards that are gone, and only those - A hand-written card duplicating a generated one fails the pod at init while every object still reports Ready, which is the gap in konveyor#153 - A skill with no frontmatter never reaches a running agent - Deleting the collection collects its cards and spares hand-authored ones `hack/run-e2e-rule.sh` is its own job, because it builds the agent image and drives the real harness against a real Konveyor. Hub comes from tackle2-operator's own Helm chart, pinned, so nothing about its deployment is defined here. It answers what used to need a live key: the emulator prints every request body it receives, so the assertion is the bytes goose put on the wire rather than something the run reports about itself. ``` PASS: with the rule: the rule arrived under ## Rules in the prompt goose sent PASS: without the rule: no marker, so the marker above was caused by the rule PASS: the harness reported the rule as always-loaded PASS: with the rule: the agent was asked to run the command the rule demanded PASS: without the rule: no tool call, so the rule caused it ``` That is the whole cross-image contract in one claim: the marker cannot appear unless the loader wrote the manifest and the harness read it back. The emulator answers the prompt with the tool call the rule demanded, but only when the marker is present, so the call is caused by the rule having arrived rather than by the task. The control matters, because one run proves nothing on its own, and both runs are expected to succeed: a control whose expected outcome is a failed run passes for free on any broken cluster. Both suites were run against deliberate breakage, because an assertion never seen to fail has not been tested. Detaching the rule card fails all three attached-side assertions while both controls still pass. Removing the RBAC provisioning and rebuilding the controller fails the identity scenario, naming the namespace. Worth knowing for anyone wiring the harness to Hub: the operator denies all ingress to its namespace except to the UI, which proxies the Hub API under `/hub`, so that is the way in from anywhere else. Going straight at the `tackle-hub` Service only works where nothing enforces NetworkPolicy. I think that is why the probe this replaces passed on minikube: kindnet enforces it and minikube's default CNI does not, so the same call times out here. Two bugs surfaced building this, either of which would have made the skills suite vacuous. `setup-e2e.sh` built the skill bundle and never loaded it into the node. And tagging it `:latest` made Kubernetes default `imagePullPolicy` to `Always`, so the kubelet ignored the loaded image and tried to pull one that exists nowhere; the single-skill examples passed throughout precisely because their tags are not `latest`, which is what hid it. The rule test takes 21s on a warm cluster, so in CI it should cost the agent image build and the Konveyor install rather than the test itself. `make lint` clean on all three modules, 55 envtest specs, controller coverage 81.5%. ## Bugs found while building this Two are fixed here. Two are not mine to fix and are called out so they are not discovered later. **Fixed: the inline ConfigMap was keyed on the SkillCard alone.** Two runs sharing one inline card collided; the second rewrote the owner reference and its deletion collected the ConfigMap out from under the first. Now scoped to the run. **Fixed: `copyTree` followed symlinks out of the source.** Resolving links is what makes a ConfigMap source work, but skill content is written by whoever published the image, so a link to the init container's projected ServiceAccount token would have copied it into the root the agent reads. Now bounded to the source, and `.git` is excluded because a tokenized clone URL lands in `.git/config`. **Pre-existing, not fixed here: a user-supplied env var that collides with a controller-set one makes the Sandbox invalid.** The controller sets `KONVEYOR_ACP_SECRET_KEY` and then appends `spec.env`, and the Sandbox CRD rejects duplicate env names: ``` Sandbox.agents.x-k8s.io "e2e-live" is invalid: spec.podTemplate.spec.containers[0].env[9]: Duplicate value: {"name":"KONVEYOR_ACP_SECRET_KEY"} ``` The AgentRun sits at `Pending`/`SandboxCreationFailed` with the cause buried in a condition. `agentrun_controller.go` claims "user-specified sources last: for duplicate keys, later entries win", which is not true for this CRD. Both lines predate this branch. Needs its own issue. **Pre-existing, not fixed here: a hand-written card can silently collide with a generated one.** A hand-authored SkillCard and a collection-generated card for the same skill in the same image are two different card names carrying the same frontmatter name. Both report `Ready=True`, the Agent reports `AllDependenciesReady`, and the pod then fails at init: ``` duplicate skill name "plan": konveyor-bundle-plan and my-hand-written-plan ``` Failing loudly at init is the intended behaviour and better than the previous silent first-wins dedup, but nothing warns at apply time. Discussed in konveyor#153. ## Not done - No run has exercised a private git source or a private image; konveyor#154 - Skill images are no longer distinguishable from any other OCI image, which matters only if a mirroring workflow enumerates them; konveyor#155 - No live model has read a rule. The e2e proves the rule reaches the model's input and that the agent acts on the reply, with a scripted endpoint standing in for the model. What a real one does with it is the one claim a fake cannot make - The shipped skills still hardcode `/opt/skills/*/references/` globs in six places across four files. Relative paths resolve now that a skill is mounted as a directory the runtime loads, but the fix is skill-author content and belongs with the conformance pass in konveyor#120, not here <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added skill delivery from OCI images, Git repositories, and inline content. * Added support for source subpaths and Git branches, tags, or commits. * Added image-based skill collections with automatic SkillCard discovery and cleanup. * Added always-loaded rules to agent prompts. * Added skill validation and materialization tooling. * **Bug Fixes** * Improved validation for malformed, duplicate, missing, or unsafe skills. * Added clearer status reporting for image, inline, and source delivery. * **Documentation** * Updated packaging, delivery, migration, and sample configuration guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Fabian von Feilitzsch <fabian@fabianism.us> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bumps [golang.org/x/net](https://github.com/golang/net) from 0.53.0 to 0.55.0. - [Commits](golang/net@v0.53.0...v0.55.0) --- updated-dependencies: - dependency-name: golang.org/x/net dependency-version: 0.55.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
changed the title
dependabot
Bot
force-pushed
the
dependabot/go_modules/golang.org/x/net-0.55.0
branch
from
August 27, 2026 09:24
df86d22 to
39ec371
Compare
Author
|
Looks like golang.org/x/net is up-to-date now, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/go_modules/golang.org/x/net-0.55.0
branch
August 31, 2026 16:36
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 golang.org/x/net from 0.53.0 to 0.55.0.
Commits
7770ec4go.mod: update golang.org/x dependencies4ece7b6html: escape greater-than symbol in doctype identifiers08be507html: improve Noah's Ark clause performancea8fb2fehtml: properly render fostered elements in foreign content0dc5b7ahtml: properly check namespace in "in body" any other end taga452f3chtml: ignore duplicate attributes during tokenizationf865199quic: fix appendMaxDataFrame erroneously accumulating sentLimit210ed3cquic: establish a "happened-before" relationship between stream write and readad8140equic: fix buffer slicing when handling overlapping stream data23ee2efhttp2: avoid API changes when built with go1.27