`git`+`tag` fails after first install
rix0rrr opened this issue · 4 comments
My GitHub workflow file looks like this:
- name: Install typst
uses: baptiste0928/cargo-install@v3
with:
git: https://github.com/typst/typst
tag: v0.10.0
crate: typst-cli
First run
The first run of this workflow went perfectly:
Installing typst-cli...
Fetching git commits for https://github.com/typst/typst...
Resolved tag v0.10.0 to commit 70ca0d257bb4ba927f63260e20443f244e0bb58c
Installation settings:
repository: https://github.com/typst/typst
commit: 70ca0d257bb4ba927f63260e20443f244e0bb58c
path: /home/runner/.cargo-install/typst-cli
key: cargo-install-typst-cli-70ca0d2-7d85079d63d8ab080a5b
No cached version found, installing typst-cli using cargo...
Added /home/runner/.cargo-install/typst-cli/bin to PATH.
Subsequent runs
However, all subsequent runs fail with this error:
Run baptiste0928/cargo-install@v3
with:
git: https://github.com/typst/typst
tag: v0.10.0
crate: typst-cli
locked: true
version: latest
Installing typst-cli...
Fetching git commits for https://github.com/typst/typst...
Error: Failed to resolve tag v0.10.0 for https://github.com/typst/typst
The upstream repository did not delete the tag in the mean time, it's still there: https://github.com/typst/typst/tree/v0.10.0
I imagine this is a problem with how caching is handled?
Looking at the source code I don't see how this could happen... and yet.
Thanks for the report. It seems that I'm not reading the git ls-remote
output correctly, which causes long outputs to be truncated sometimes. I was able to reproduce the problem with typst and cargo-make, which have both a long output for ls-remote
.
I will start working on a fix this week.
cargo-install/src/resolve/git.ts
Lines 52 to 55 in 1cd874a
Ohhhh! That makes sense. Good catch!
I have released a new version with the fix (f71cc64), let me know if it works for you.