ci: install CI dependencies from hash-pinned locks - #302
Merged
Conversation
Same pattern as trace-registry and trace-tests. Every pip install in these workflows resolved whatever PyPI served at that moment. Three locks under requirements/, each compiled from a .in whose header carries the exact regeneration command, all installed with --require-hashes. That flag is all-or-nothing: pip refuses if any requirement, transitive included, lacks a hash. The editable installs use the two-step, since pip cannot hash-pin an editable install in the same invocation: third-party dependencies come from the lock, then the local package goes in with --no-deps. Two installs in publish.yml are deliberately left alone. They install dist/*.whl and dist/*.tar.gz, the artifacts the job has just built, and pinning those would defeat the verification they exist to perform. Locks are universal and compiled against 3.11, the floor in requires-python, so they hold across the 3.11/3.12 matrix. Verified in a clean venv: the lock installs under --require-hashes and the suite is 1213 passed against the 4 failures that reproduce on an unmodified main. Worth noting that test_docs_quickstart passes here where it fails on my machine: the editable install makes its subprocess resolve to the tree, which is exactly the shadowing the new conftest guard detects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t
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
1 participant
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.
Same pattern as agentrust-io/trace-registry#67 (merged, green) and agentrust-io/trace-tests#101.
Three locks under
requirements/, each compiled from a.inwhose header carries the exact regeneration command:dev.txt[project.dependencies]plus thedevextradocs.txtbuild.txthatchlingfor the release pathAll installed with
--require-hashes, which is all-or-nothing: pip refuses if any requirement, transitive included, lacks a hash.Editable installs use the two-step, since pip cannot hash-pin an editable install in the same invocation.
Deliberately not pinned
publish.ymlinstallsdist/*.whlanddist/*.tar.gz— the artifacts that job has just built. Pinning those would defeat the verification they exist to perform, so they stay as they are.Verification
Clean venv: the lock installs under
--require-hashes, and the suite gives 1213 passed against the 4 failures that reproduce on an unmodifiedmain(three fixture-regeneration tests and one schema-classification test).One detail worth calling out:
test_docs_quickstartpasses here where it fails on my machine. Its subprocess resolvesagentrust_traceto the editable tree in this setup, rather than to a shadowing PyPI install — which is precisely the failure mode the conftest guard added in #301 detects.🤖 Generated with Claude Code
https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t