* 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.
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>
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.
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.
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>
@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.
