@dscho discovered that the checkout action could stall for a considerable amount of time on Windows runners waiting for PowerShell invocations made from 'windows-release' npm package to complete.
Then I studied the dependency chain to figure out where 'windows-release' was imported:
'@actions/github' v3 removed dependency on '@octokit/rest'@16.43.1 and allows users to move away from the old 'universal-user-agent' v4. (https://github.com/actions/toolkit/pull/453)
This pull request attempts to update the version of '@actions/github' used in the checkout action to avoid importing 'windows-release'.
Based on testing in my own repositories, I can see an improvement in reduced wait time between entering the checkout action and git actually starts to do useful work.
When trying to list local branches to figure out what needs cleaned up during runs on non-ephemeral Actions Runners, we use git rev-parse --symbolic-full-name to get a list of branches. This can lead to ambiguous ref name errors when there are branches and tags with similar names.
Part of the reason we use rev-parse --symbolic-full-name vs git branch --list or git rev-parse --symbolic seems to related to a bug in Git 2.18. Until we can deprecate our usage of Git 2.18, I think we need to keep --symbolic-full-name. Since part of the problem is that these ambiguous ref name errors clog the Actions annotation limits, this is a mitigation to suppress those messages until we can get rid of the workaround.
* auth-helper: properly await replacement of the token value in the config
After writing the `.extraheader` config, we manually replace the token with the actual value. This is done in an `async` function, but we were not `await`ing the result.
In our tests, this commit fixes a flakiness we observed where `remote.origin.url` sometimes (very rarely, actually) is not set for submodules. Our interpretation is that the configs are in the process of being rewritten with the correct token value _while_ another `git config` that wants to set the `insteadOf` value is reading the config, which is currently empty.
A more idiomatic way to fix this in Typescript would use `Promise.all()`, like this:
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* downloadRepository(): await the result of recursive deletions
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Ask ESLint to report floating Promises
This rule is quite helpful in avoiding hard-to-debug missing `await`s.
Note: there are two locations in `src/main.ts` that trigger warnings: the `run()` and the `cleanup()` function are called without `await` and without any `.catch()` clause.
In the initial version of https://github.com/actions/checkout/pull/379, this was addressed by adding `.catch()` clauses. However, it was determined that this is boilerplate code that will need to be fixed in a broader way.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Rebuild
This trick was brought to you by `npm ci && npm run build`. Needed to get the PR build to pass.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
