weaver registry check --policy <url>@<ref>[<sub>] panics in gix when
<ref> is a commit SHA. Tags and branches work (added in #1201).
Reproduced on otel/weaver:v0.23.0; still present on main as of
4fb176a. Likely the unfinished part of #182.
Repro
docker run --rm otel/weaver:v0.23.0 registry check -r ./model \
--policy 'https://github.com/open-telemetry/opentelemetry-weaver-packages.git@d84341cf20a1fef1a833ef44d318c41a770e6e64[policies/check/naming_conventions]'
(any non-empty ./model triggers it; replacing the SHA with main succeeds.)
Output
thread 'main' (1) panicked at .../gix-0.81.0/src/clone/fetch/util.rs:217:18:
we map by name only and have no object-id in refspec
Cause
[vdir.rs:659](https://github.com/open-telemetry/weaver/blob/main/crates/weaver_common/src/vdir.rs#L659)
passes the raw refspec into gix::clone::PrepareFetch::with_ref_name,
which is only valid for symbolic refs. A 40-char hex object id can't
be resolved to a name, so gix panics.
Fix probably needs to detect a hex SHA and route to a separate fetch
path (fetch by object id), or reject it with a proper error message.
Workaround 1
git fetch --depth 1 origin <sha> accepts SHAs; materialize the pack locally and point --policy at the checkout.
weaver registry check --policy <url>@<ref>[<sub>]panics in gix when<ref>is a commit SHA. Tags and branches work (added in #1201).Reproduced on
otel/weaver:v0.23.0; still present onmainas of4fb176a. Likely the unfinished part of #182.Repro
Output
Fix probably needs to detect a hex SHA and route to a separate fetch
path (fetch by object id), or reject it with a proper error message.
Workaround 1
git fetch --depth 1 origin <sha>accepts SHAs; materialize the pack locally and point --policy at the checkout.