Using cargo-binstall with Gitea/Forgejo Actions

[paulvt]

I am using Gitea/Forgejo Actions to set up my CI. It (re)uses GitHub Actions to set up the steps and I really want to use cargo-binstall to speed things up. However, I am running into the issue that Actions sets the GITHUB_TOKEN environment variable (next to GITEA_TOKEN/FORGEJO_TOKEN) to be backwards compatible, and this works fine overall, except... when calling cargo-binstall.

It sees that this environment variable is set and starts to use it to do GitHub API queries for releases if I gather that correctly from the debug logs and I cannot get it to not use it.
This is comparable with running env GITHUB_TOKEN="foo" cargo binstall .... Even setting GITHUB_TOKEN to empty doesn't help. What would be the best approach here? Now it just retries 3 times and then it succeeds, but this costs 360s, almost the entire time that using cargo binstall instead of cargo install saves me 😅

[passcod]

We should probably check if the env variable is empty, but in the meantime have you tried unsetting the env var instead?

- shell: bash
  run: |
    unset GITHUB_TOKEN
    cargo binstall ...

[paulvt]

That also occurred to me and that works!
The only remaining issue is now the cargo-bins/cargo-binstall action which is a script that I have no control over. So, I guess I have to do a manual install somehow instead? The action works, but, it just takes 5 minutes.

[NobodyXu]

Opened #1839 for this

[paulvt]

Thanks for the quick response! It makes sense that an empty token should not be considered as a token.
I will try (as soon as I can get my hands on the fixed cargo-binstall binary) with:

      - name: Install cargo-binstall
        uses: https://github.com/cargo-bins/cargo-binstall@main
        env:
          GITHUB_TOKEN: ""

and report back and/or close the discussion.

[NobodyXu]

I'm cutting new releases, however given that there's a breaking change there's a lot to release

If you subscribe to this repo's releases you'd be notified when it's ready.

[paulvt]

As a way to sidestep this cargo-binstall action issue in workflows, it seems that if you use the "Rust" variant of the images suggested by the Gitea/Forgejo Actions projects, it already contains cargo-binstall by default!
One still needs to unset/clear GITHUB_TOKEN when calling cargo-binstall of course.