sources: commit-SHA refs; recipes: schema v2 dependency manifests - #345
Merged
Conversation
40-hex commit SHA refs already resolved via fetch + checkout (#282). A repository using git's SHA-256 object format (`git init --object-format=sha256`, git >= 2.29) names every commit with 64 hex characters instead, so its commit pins still fell through to `git clone --branch <sha>` and failed with "Remote branch <sha> not found in upstream origin" -- the exact failure the 40-hex fix removed, for a different population of repositories. - _FULL_COMMIT_SHA_PATTERN now matches 40 OR 64 hex characters. Nothing in between (or above) is a full commit id in any object format git currently has, so the abbreviated/ambiguous refs keep falling through to the --branch path and its clear error. - _clone_at_commit inits the destination with --object-format=sha256 for a 64-hex sha. The destination's object format must match the remote's or the shallow fetch cannot name the commit at all ("couldn't find remote ref <sha>", measured on git 2.43); without this the SHA-256 case still resolved correctly but silently gave up the shallow fast path on every clone. `git clone` infers the format from the remote; `git init` cannot, so it has to be told. Branch/tag refs and the 40-hex path are untouched -- the existing 40-hex shallow-fetch test asserts .git/shallow, which fails if the sha256 init flag leaks onto the SHA-1 path. Known, deliberate divergence recorded in the code: SourceStatus.is_pinned (sources/protocol.py) still recognises only 40-hex, so a 64-hex ref resolves but is not reported as pinned by get_status(). Effect is a needless ls-remote on status, never a wrong resolve; widening it is a separate change in a file this one does not own. Tests: local git fixtures only, no network. SHA-256 cases probe the local git for --object-format support and skip if absent.
…3wt) validate-agents.yaml (v1.4.0 -> 1.5.0), validate-bundle.yaml (2.0.0 -> 2.1.0) and validate-single-bundle.yaml (2.2.0 -> 2.3.0) now declare `schema_version: 2` plus a `dependencies` block pinned to the released foundation tag @v2.1.2, listing `foundation:zen-architect` under `required_agents`. Every `agent:` reference in these three recipes previously resolved out of the CALLING session's agent map, which is the original reported failure: "Agent 'foundation:zen-architect' not found in configuration". Under a v2-aware host those references now resolve from the recipe's own declared closure, so that failure is structurally impossible. The declaration is self-referential on purpose -- foundation's own recipes declare foundation as a dependency. Core 11 forbids inferring a source from the `foundation:` namespace prefix. Verified against the SHIPPED parser + planner with the real FoundationResolver and no caller agents (plan() has no parameter for one): all three PLAN clean, resolving foundation:zen-architect from git+https://github.com/microsoft/amplifier-foundation@v2.1.2 at revision a27d582. Both discriminating negatives fire: the pre-migration file is refused as LegacyRecipeError, and the same body with `dependencies: []` raises UndeclaredAgentError naming the agent, the step, and the remedy. Legacy compatibility holds: all three still load under Recipe.from_yaml + validate_recipe (valid=True, 0 errors, 0 warnings), and the legacy Recipe model is byte-identical apart from the deliberate version bump -- the engine never reads the two new top-level keys. No step, prompt or logic was changed. tests/test_yaml_structure_lint.py carries a hard-pinned assertion on validate-single-bundle's version field; bumped 2.2.0 -> 2.3.0 alongside it. Full suite: 1675 passed, 1 skipped.
…s-sro) Follow-up to recipes-xjo: the git handler resolves 40- and 64-hex SHAs, but SourceStatus.is_pinned hard-coded len==40, so a SHA-256-pinned source did a needless ls-remote and reported update state for an immovable ref.
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
2 participants
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.
What changed
1. Git source handler resolves commit-SHA refs.
amplifier_foundation/sources/git.pynow recognises a full 40-hex SHA-1 or 64-hex SHA-256 commit id as arefand resolves it via fetch + checkout, instead ofclone --branch(which only ever worked for branch/tag names and failed on a raw commit id).2.
SourceStatus.is_pinnedrecognises 64-hex refs.Previously only 40-hex SHA-1 counted as pinned, so a SHA-256 commit ref was silently reported as unpinned.
3. The three validator recipes declare
schema_version: 2.validate-agents,validate-bundle, andvalidate-single-bundlenow carry aschema_version: 2dependency manifest with a self-referential foundation dependency pinned at@v2.1.2, so their agents resolve from their own declared dependencies rather than by borrowing whatever bundle the caller happened to have loaded.This fixes the failure:
under v2-aware hosts. The recipes still load unchanged under the legacy engine.
Why
These are the foundation-side companions to the recipe-runner work in
amplifier-bundle-recipes(see that repo's stacked implementation PR). Pinning a dependency to an exact commit is only useful if the source handler can actually check that commit out and correctly report it as pinned — (1) and (2) make that true. (3) is what makes the validator recipes self-contained under a v2-aware host.How to verify
tests/test_sources.pygrew from 50 to 56 collected tests (verified by--collect-only), covering SHA-1 and SHA-256 ref resolution and theis_pinnedclassification, including negative cases (non-hex 64-char strings are not pinned).The three migrated recipes were exercised against both the v2-aware host and the legacy engine.
Breaking changes
None. Commit-SHA refs were previously an error path, not a working behaviour; branch and tag refs are unchanged. The migrated recipes remain loadable by the legacy engine.
Rollout / migration notes
N/A — no config migration, no data migration, no flag to flip.