Description
Current behavior 😯
Sometime in the last couple of weeks and probably in the last few days, the Run taiki-e/install-action@v1
step in the test-fast
job on windows-latest
fails whenever it is run, showing:
Run taiki-e/install-action@v1
with:
tool: nextest
env:
CARGO_TERM_COLOR: always
CLICOLOR: 1
CARGO_HOME: C:\Users\runneradmin/.cargo
CARGO_INCREMENTAL: 0
CACHE_ON_FAILURE: false
info: installing nextest@latest
info: downloading https://get.nexte.st/latest/windows-tar
tar: C\:\\Users\runneradmin/.cargo/bin: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
curl: ([2](https://github.com/EliahKagan/gitoxide/actions/runs/8969527945/job/24655063846#step:8:2)3) Failure writing output to destination
curl: (2[3](https://github.com/EliahKagan/gitoxide/actions/runs/8969527945/job/24655063846#step:8:3)) Failure writing output to destination
curl: (23) Failure writing output to destination
curl: (23) Failure writing output to destination
curl: (23) Failure writing output to destination
curl: (23) Failure writing output to destination
Error: Command failed: bash --noprofile --norc D:\a\_actions\taiki-e\install-action\v1/main.sh
I don't know specifically what is causing this, but experiments within my fork strongly suggest that it can be solved by upgrading taiki-e/install-action
to a current version of the action.
I'm opening this issue rather than only a PR because there is more than one reasonable approach that could be taken to do this, and because I had needed to do some more experimentation, but I have opened #1356 to fix this.
Expected behavior 🤔
The action should successfully complete, installing nextest
as intended. This is the behavior on all three test-fast
-tested platforms until very recently, and remains the behavior except on Windows.
Git behavior
Not applicable, as this is a CI setup issue not identifiably related to any problem in gitoxide's code or test suite.
Steps to reproduce 🕹
Because the job has not run in this upstream gitoxide repository since the problem began, and because CI is not configured to run on feature branches except in PRs, so far this has not occurred on this upstream repository's main branch due to the push
trigger, but I have reproduced it in two ways in my fork as well as in this upstream repository with the pull_request
trigger:
- On a branch in my fork where I have modified the workflow to trigger even though it is a feature branch. Notice how, when further modified to use
v2
rather thanv1
as the major version of the action, the problem goes away. - On the main branch of my fork, by rerunning it. Notice how multiple runs fail, so it is not a one-off problem, and how the first run, from when I synchronized the fork with the most recent push (as of this writing) to the upstream repository, succeeded.
- In this upstream repository, on #1357, from the
pull_request
trigger, in this failing job. Note that no corresponding failure happens in #1356, even though the job runs there, because #1356 provides a fix for this issue.