Describe the Bug
atmos vendor update (and --pull-request) correctly detects a newer version and updates the version: field in vendor.yaml, but for sources that encode the git ref via a query string (e.g. source: "github.com/org/repo.git//?ref={{.Version}}"), the subsequent re-fetch is silently skipped. The vendor-lock drift check (pkg/vendoring/lockfile.IsMaterialized) decides the target is still "materialized" and never re-downloads, so the actual vendored files are never updated — only the version: string in vendor.yaml changes.
Root cause: pkg/downloader/artifact.go's RedactSource — used to normalize/compare the "declared source" recorded in vendor.lock.yaml — unconditionally strips the URL's query string (parsed.RawQuery = "") to redact embedded credentials before persisting/logging a source URL. But when a source encodes its version as a query parameter (?ref=0.24.0 → ?ref=0.25.0), redaction also erases the version, making both versions compare as identical to the lock's drift check (pkg/vendoring/install/install.go's FilterPending → isMaterialized). Result: the lock incorrectly treats a real version bump as "no drift," and the download is skipped.
?ref={{.Version}} is the standard, documented way to version-pin a git-based vendor source in Atmos (it's used in website/docs/cli/configuration/vendor.mdx's own examples, and in examples/scaffolding, examples/demo-vendoring, and examples/demo-component-versions), so this isn't a narrow edge case — it likely affects most real-world atmos vendor update usage against git sources.
Expected Behavior
Bumping a source's version in vendor.yaml should always trigger a re-fetch of that component's files, regardless of whether the version is expressed via a query parameter (?ref=) or elsewhere in the source string.
Steps to Reproduce
- Add a
vendor.yaml source using a query-string ref, e.g.:
spec:
sources:
- component: "null-label"
source: "github.com/cloudposse/terraform-null-label.git//?ref={{.Version}}"
version: "0.24.0"
targets: ["components/terraform/null-label"]
included_paths: ["**/*.tf", "**/*.md"]
atmos vendor pull (seeds vendor.lock.yaml at 0.24.0).atmos vendor update --pull (0.25.0 is available and gets discovered).- Observe:
vendor.yaml's version: field updates to 0.25.0, but the files under components/terraform/null-label are byte-identical to before, and files added upstream between the two versions (e.g. a new descriptors.tf in this repro) never appear.
- Debug logs (
ATMOS_LOGS_LEVEL=Debug) show: Vendor target matches immutable lock receipt; skipping download.
Environment
Additional Context
Likely fix direction: RedactSource's job is stripping credentials (userinfo, and presumably token-bearing query params), not the ref/version itself. Either exempt ref-like query params from redaction when computing the lock's comparison key, or track the declared version separately from the redacted source string so drift detection can independently ask "did the on-disk content change" and "did the declared version change."
Describe the Bug
atmos vendor update(and--pull-request) correctly detects a newer version and updates theversion:field invendor.yaml, but for sources that encode the git ref via a query string (e.g.source: "github.com/org/repo.git//?ref={{.Version}}"), the subsequent re-fetch is silently skipped. The vendor-lock drift check (pkg/vendoring/lockfile.IsMaterialized) decides the target is still "materialized" and never re-downloads, so the actual vendored files are never updated — only theversion:string invendor.yamlchanges.Root cause:
pkg/downloader/artifact.go'sRedactSource— used to normalize/compare the "declared source" recorded invendor.lock.yaml— unconditionally strips the URL's query string (parsed.RawQuery = "") to redact embedded credentials before persisting/logging a source URL. But when a source encodes its version as a query parameter (?ref=0.24.0→?ref=0.25.0), redaction also erases the version, making both versions compare as identical to the lock's drift check (pkg/vendoring/install/install.go'sFilterPending→isMaterialized). Result: the lock incorrectly treats a real version bump as "no drift," and the download is skipped.?ref={{.Version}}is the standard, documented way to version-pin a git-based vendor source in Atmos (it's used inwebsite/docs/cli/configuration/vendor.mdx's own examples, and inexamples/scaffolding,examples/demo-vendoring, andexamples/demo-component-versions), so this isn't a narrow edge case — it likely affects most real-worldatmos vendor updateusage against git sources.Expected Behavior
Bumping a source's version in
vendor.yamlshould always trigger a re-fetch of that component's files, regardless of whether the version is expressed via a query parameter (?ref=) or elsewhere in the source string.Steps to Reproduce
vendor.yamlsource using a query-string ref, e.g.:atmos vendor pull(seedsvendor.lock.yamlat 0.24.0).atmos vendor update --pull(0.25.0 is available and gets discovered).vendor.yaml'sversion:field updates to0.25.0, but the files undercomponents/terraform/null-labelare byte-identical to before, and files added upstream between the two versions (e.g. a newdescriptors.tfin this repro) never appear.ATMOS_LOGS_LEVEL=Debug) show:Vendor target matches immutable lock receipt; skipping download.Environment
pkg/vendoring/lockfile/pkg/downloaderbug, not specific to any pull-request provider.atmosbuilt frommainat commit7f090db0f(plus the unrelated PR feat(vendor): add Azure DevOps pull-request provider #3048 branch, which doesn't touch this code path).Additional Context
Likely fix direction:
RedactSource's job is stripping credentials (userinfo, and presumably token-bearing query params), not the ref/version itself. Either exempt ref-like query params from redaction when computing the lock's comparison key, or track the declared version separately from the redacted source string so drift detection can independently ask "did the on-disk content change" and "did the declared version change."