8 Commits

Include renames

Author	SHA1	Message	Date
Aiqiao Yan	d914b262ff	upgrade module to esm and update dependencies (#2463) ... * upgrade module to esm so I can update dependencies * fix ci failures	2026-06-16 17:10:58 -04:00
Yashwanth Anantharaju	1cce3390c2	Fix checkout init for SHA-256 repositories (#2439) ... * Fix checkout init for SHA-256 repositories * Remove unused object format result field	2026-06-01 11:35:58 -04:00
eric sciple	de0fac2e45	Fix tag handling: preserve annotations and explicit fetch-tags (#2356) ... 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	2026-01-09 13:42:23 -06:00
4 people	064fe7f331	Add orchestration_id to git user-agent when ACTIONS_ORCHESTRATION_ID is set (#2355) ... * 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>	2026-01-08 15:07:38 -05:00
Simon Baird	8b5e8b7687	Support fetching without the --progress option (#1067) ... 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>	2023-09-01 14:19:18 -04:00
Robert Wieczoreck	7739b9ba2e	Add option to fetch tags even if fetch-depth > 0 (#579) ... * Add option to fetch tags even if fetch-depth > 0 * Add jest tests for fetchDepth and fetchTags options	2023-08-16 16:34:54 -04:00
Johannes SchindelinandDaniel	d106d4669b	Add support for sparse checkouts (#1369) ... * 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>	2023-06-09 09:08:21 -04:00
Cory Miller	8856415920	Implement branch list using callbacks from exec function (#1045) ... 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.	2022-12-14 16:08:53 -05:00