- Kill git process on timeout: use child_process.spawn directly for
timeout-eligible operations so we have a ChildProcess handle to send
SIGTERM (then SIGKILL after 5s). On Windows, SIGTERM is a forced kill
so the SIGKILL fallback is effectively a no-op there.
- Fix timeout:0 not working: replace falsy || coalescion with explicit
empty-string check so that '0' is not replaced by the default '300'.
- Refactor execGit to use an options object instead of 5 positional
parameters, eliminating error-prone filler args (false, false, {}).
- Pass allowAllExitCodes through to execGitWithTimeout so both code
paths have consistent behavior for non-zero exit codes.
- Add settled guard to prevent double-reject when both close and error
events fire on the spawned process.
- Handle null exit code (process killed by signal) as an error rather
than silently treating it as success.
- Capture stderr in error messages for the timeout path, matching the
information level of the non-timeout exec path.
- Log SIGKILL failures at debug level instead of empty catch block.
- Warn on customListeners being ignored in the timeout path.
- Emit core.warning() when invalid input values are silently replaced
with defaults, so users know their configuration was rejected.
- Add input validation in setTimeout (reject negative values).
- Clarify retry-max-attempts semantics: total attempts including the
initial attempt (3 = 1 initial + 2 retries).
- Remove Kubernetes probe references from descriptions.
- Use non-exhaustive list (e.g.) for network operations in docs to
avoid staleness if new operations are added.
- Add tests for timeout/retry input parsing (defaults, timeout:0,
custom values, invalid input with warnings, backoff clamping) and
command manager configuration (setTimeout, setRetryConfig, fetch).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This PR fixes several issues with tag handling in the checkout action:
1. fetch-tags: true now works (fixes#1471)
- Tags refspec is now included in getRefSpec() when fetchTags=true
- Previously tags were only fetched during a separate fetch that was
overwritten by the main fetch
2. Tag checkout preserves annotations (fixes#290)
- Tags are fetched via refspec (+refs/tags/*:refs/tags/*) instead of
--tags flag
- This fetches the actual tag objects, preserving annotations
3. Tag checkout with fetch-tags: true no longer fails (fixes#1467)
- When checking out a tag with fetchTags=true, only the wildcard
refspec is used (specific tag refspec is redundant)
Changes:
- src/ref-helper.ts: getRefSpec() now accepts fetchTags parameter and
prepends tags refspec when true
- src/git-command-manager.ts: fetch() simplified to always use --no-tags,
tags are fetched explicitly via refspec
- src/git-source-provider.ts: passes fetchTags to getRefSpec()
- Added E2E test for fetch-tags option
Related #1471, #1467, #290
* Initial plan
* Add orchestration ID support to git user-agent
Co-authored-by: TingluoHuang <1750815+TingluoHuang@users.noreply.github.com>
* Apply suggestion from @Copilot
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Improve tests to verify user-agent content and handle empty sanitized IDs
Co-authored-by: TingluoHuang <1750815+TingluoHuang@users.noreply.github.com>
* Simplify orchestration ID validation to accept any non-empty sanitized value
Co-authored-by: TingluoHuang <1750815+TingluoHuang@users.noreply.github.com>
* Remove test for orchestration ID with only invalid characters
Co-authored-by: TingluoHuang <1750815+TingluoHuang@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: TingluoHuang <1750815+TingluoHuang@users.noreply.github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
Co-authored-by: Copilot <175728472+Copilot@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>
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.
