* README: Set `user.email` to GitHub Actions Bot
* Update workflow to use proper bot GitHub Bot email
* Prefix `user.email` with `41898282+`
To match squash merge user, else showing as two different users, see: b0948d0da0
* Update README.md
---------
Co-authored-by: Pelle Wessman <pelle@kodfabrik.se>
* Check git version before attempting to disable `sparse-checkout`
* Bump `MinimumGitSparseCheckoutVersion` to 2.28 due to #1386
* Initial prep for release 4.1.3
* Give `test-ubuntu-git` its own `README`
* Refined title and description in `test-ubuntu-git.Dockerfile`
* nit accepted: Remove double space
---------
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
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>
Currently, a check is done after fetch to ensure that the repo state has
not changed since the workflow was triggered. This check will reset the
checkout to the commit that triggered the workflow, even if the branch
or tag has moved since.
The issue is that the check currently sees what "object" the ref points
to. For an annotated tag, that is the annotation, not the commit. This
means the check always fails for annotated tags, and they are reset to
the commit, losing the annotation. Losing the annotation can be fatal,
as `git describe` will only match annotated tags.
The fix is simple: check if the tag points at the right commit, ignoring
any other type of object. This is done with the <rev>^{commit} syntax.
From the git-rev-parse docs:
> <rev>^{<type>}, e.g. v0.99.8^{commit}
> A suffix ^ followed by an object type name enclosed in brace pair
> means dereference the object at <rev> recursively until an object of
> type <type> is found or the object cannot be dereferenced anymore (in
> which case, barf). For example, if <rev> is a commit-ish,
> <rev>^{commit} describes the corresponding commit object. Similarly,
> if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree
> object. <rev>^0 is a short-hand for <rev>^{commit}.
If the check still fails, we will still reset the tag to the commit,
losing the annotation. However, there is no way to truly recover in this
situtation, as GitHub does not capture the annotation on workflow start,
and since the history has changed, we can not trust the new tag to
contain the same data as it did before.
Fixes#290Closes#697
* 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>
In #1369, I mistakenly replaced the hash-bang lines in the two new
scripts with `#!/bin/sh`, missing that both files contain the Bash'ism
`[[`. Symptom as per
https://github.com/actions/checkout/actions/runs/5200323109/jobs/9378889172?pr=1369#step:12:5
__test__/verify-sparse-checkout.sh: 58: [[: not found
Let's change those hash-bang lines back to `#!/bin/bash`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* 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>
Mark Vander Stel