Checking out certain `ref` values will result in a warning about a detached `HEAD`:
```
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
```
However, this warning isn't useful in a CI environment... so suppress it.
I realize on the original bug report that one user mentioned this warning
highlighted a bug in his actions flow, but I consider that a super rare / happy accident.
99% of use cases will be _intentionally_ checking out a specific ref where
the detached head state is inevitable, so the warning is pure noise.
Passing the config this way sets it _only_ for this command. Note that it
must be set [_before_ calling `checkout`](https://stackoverflow.com/a/72588008/770425).
Resolve: https://github.com/actions/checkout/issues/494
* Adding the ability to specify the GitHub Server URL and allowing for it to differ from the Actions workflow host
* Adding tests for injecting the GitHub URL
* Addressing code review comments for PR #922
* 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:
await Promise.all(
configPaths.map(async configPath => {
core.debug(`Replacing token placeholder in '${configPath}'`)
await this.replaceTokenPlaceholder(configPath)
})
)
However, during review of https://github.com/actions/checkout/pull/379
it was decided to keep the `for` loop in the interest of simplicity.
Reported by Ian Lynagh.
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>
