git+tag fails after first install

[rix0rrr]

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?

[rix0rrr]

Looking at the source code I don't see how this could happen... and yet.

[baptiste0928]

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

	await exec.exec('git', ['ls-remote', repository], { outStream: commandOutput })
	const commits: GitRemoteCommits = { head: '', tags: {}, branches: {} }
	const lines: string[] = commandOutput.read().toString().split('\n')

[rix0rrr]

Ohhhh! That makes sense. Good catch!

[baptiste0928]

I have released a new version with the fix (f71cc64), let me know if it works for you.