* Check git version before attempting to disable `sparse-checkout`
* Bump `MinimumGitSparseCheckoutVersion` to 2.28 due to #1386
* Initial prep for release 4.1.3
When a worktree is reused by actions/checkout and the first time sparse checkout was enabled, we need to ensure that the second time it is only a sparse checkout if explicitly asked for. Otherwise, we need to disable the sparse checkout so that a full checkout is the outcome of this Action.
## Details
* If no `sparse-checkout` parameter is specified, disable it
This should allow users to reuse existing folders when running
`actions/checkout` where a previous run asked for a sparse checkout but
the current run does not ask for a sparse checkout.
This fixes https://github.com/actions/checkout/issues/1475
There are use cases in particular with non-ephemeral (self-hosted) runners where an
existing worktree (that has been initialized as a sparse checkout) is
reused in subsequent CI runs (where `actions/checkout` is run _without_
any `sparse-checkout` parameter).
In these scenarios, we need to make sure that the sparse checkout is
disabled before checking out the files.
### Also includes:
* npm run build
* ci: verify that an existing sparse checkout can be made unsparse
* Added a clarifying comment about test branches.
* `test-proxy` now uses newly-minted `test-ubuntu-git` container image from ghcr.io
---------
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Co-authored-by: John Wesley Walker III <81404201+jww3@users.noreply.github.com>
* added filter option & tests
* added build file
* fix test oversight
* added exit 1
* updated docs to specify override
* undo unneeded readme change
* set to undefined rather than empty string
* run git config in correct di
---------
Co-authored-by: Cory Miller <13227161+cory-miller@users.noreply.github.com>
Setting the `show-progress` option to false in the `with` section of the
workflow step will cause git fetch to run without `--progress`.
The motivation is to be able to suppress the noisy progress status
output which adds many hundreds of "remote: Counting objects: 85%
(386/453)" and similar lines in the workflow log.
This should be sufficient to resolve#894 and its older friends,
though the solution is different to the one proposed there because
it doesn't use the --quiet flag. IIUC git doesn't show the progress
status by default since the output is not a terminal, so that's why
removing the --progress option is all that's needed.
Adding the --quiet flag doesn't make a lot of difference once the
--progress flag is removed, and actually I think using --quiet would
suppress some other more useful output that would be better left
visible.
Signed-off-by: Simon Baird <sbaird@redhat.com>
* Add support for sparse checkouts
* sparse-checkout: optionally turn off cone mode
While it _is_ true that cone mode is the default nowadays (mainly for
performance reasons: code mode is much faster than non-cone mode), there
_are_ legitimate use cases where non-cone mode is really useful.
Let's add a flag to optionally disable cone mode.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Verify minimum Git version for sparse checkout
The `git sparse-checkout` command is available only since Git version
v2.25.0. The `actions/checkout` Action actually supports older Git
versions than that; As of time of writing, the minimum version is
v2.18.0.
Instead of raising this minimum version even for users who do not
require a sparse checkout, only check for this minimum version
specifically when a sparse checkout was asked for.
Suggested-by: Tingluo Huang <tingluohuang@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Support sparse checkout/LFS better
Instead of fetching all the LFS objects present in the current revision
in a sparse checkout, whether they are needed inside the sparse cone or
not, let's instead only pull the ones that are actually needed.
To do that, let's avoid running that preemptive `git lfs fetch` call in
case of a sparse checkout.
An alternative that was considered during the development of this patch
(and ultimately rejected) was to use `git lfs pull --include <path>...`,
but it turned out to be too inflexible because it requires exact paths,
not the patterns that are available via the sparse checkout definition,
and that risks running into command-line length limitations.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---------
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Co-authored-by: Daniel <daniel.fernandez@feverup.com>
* Fix Self hosted runner issue wrt bad submodules - solution cleanup working space.
* Fix format with npm run format output
* Add mock implementation for new function submoduleStatus
* Add 2 test cases for submodule status.
* Codeql-Action Analyse revert v1 to v2
---------
Co-authored-by: Bassem Dghaidi <568794+Link-@users.noreply.github.com>
Co-authored-by: sminnie <minnie@sankhe.com>
* Improve checkout performance on Windows runners by upgrading @actions/github dependency
Re: https://github.com/actions/checkout/issues/1186
@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/checkout'@main
<- '@actions/github'@2.2.0
<- '@octokit/endpoint'@6.0.1
<- '@octokit/graphql'@4.3.1
<- '@octokit/request'@5.4.2
<- '@octokit/rest'@16.43.1
<- 'universal-user-agent'@4.0.1
<- 'os-name'@3.1.0
<- 'windows-release'@3.1.0
'universal-user-agent' package dropped its dependency on 'os-name' in
https://github.com/gr2m/universal-user-agent/releases/tag/v6.0.0 .
'@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.
* Update .licenses
* Rebuild index.js
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.
* wrap pipeline commands for submoduleForeach in quotes
* Update src/git-auth-helper.ts
drop extraneous space.
Co-authored-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
* Followed CONTRIBUTING.md instructions, updating dist/index.js
* fixed package-lock.json
* updating the pipeline so it runs from sh
Co-authored-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
* 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
When checking out a repository with full history, a full clone is done
and then the ref is finally updated to point to the commit that caused
the workflow to be run. Normally, this is a good protection against
someone pushing to the repository twice in short succession, but it
causes problems with annotated tags.
Specifically, because the entry in refs/tags is set to the commit hash,
if an annotated tag was used, the tag is turned merely into a
lightweight one, which breaks `git describe`. Every other tag in the
repository will continue to remain a valid annotated tag except the one
for which the workflow was invoked, which is not what the user expected.
Let's work around this by not performing a fetch if what we're fetching
is a tag. Technically, annotated tags can be anywhere in the hierarchy
at any ref, but this should work as a suitable heuristic for now.
Note that the proper solution would be to expose the revision of the
actual object and check against that instead of the commit, but it
doesn't presently appear that that information is exposed. Also, we
explicitly do not case-fold since Git refs are case sensitive.
* 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>
