Merge 1d3fa26c9e into 85e6279cec

Adjust positioning of user email note and permissions heading (#2044 )
Documentation update - add recommended permissions to Readme (#2043 )
2025-04-20 17:00:15 +03:00 · 2025-01-17 13:38:04 -05:00 · 2025-01-16 15:56:18 -05:00 · 2025-01-16 14:14:48 -05:00 · 2023-10-06 12:42:43 -04:00
3 changed files with 13 additions and 2 deletions
--- a/README.md
+++ b/README.md
@ -311,8 +311,17 @@ jobs:
          git commit -m "generated"
          git push
 ```
 *NOTE:* The user email is `{user.id}+{user.login}@users.noreply.github.com`. See users API: https://api.github.com/users/github-actions%5Bbot%5D
 # Recommended permissions
 When using the `checkout` action in your GitHub Actions workflow, it is recommended to set the following `GITHUB_TOKEN` permissions to ensure proper functionality, unless alternative auth is provided via the `token` or `ssh-key` inputs:
 ```yaml
 permissions:
  contents: read
 ```
 # License
--- a/dist/index.js
+++ b/dist/index.js
@ -2114,7 +2114,8 @@ function testRef(git, ref, commit) {
        // refs/tags/
        else if (upperRef.startsWith('REFS/TAGS/')) {
            const tagName = ref.substring('refs/tags/'.length);
-            return ((yield git.tagExists(tagName)) && commit === (yield git.revParse(ref)));
+            return ((yield git.tagExists(tagName)) &&
                commit === (yield git.revParse(`${ref}^{commit}`)));
        }
        // Unexpected
        else {
--- a/src/ref-helper.ts
+++ b/src/ref-helper.ts
@ -171,7 +171,8 @@ export async function testRef(
  else if (upperRef.startsWith('REFS/TAGS/')) {
    const tagName = ref.substring('refs/tags/'.length)
    return (
-      (await git.tagExists(tagName)) && commit === (await git.revParse(ref))
+      (await git.tagExists(tagName)) &&
      commit === (await git.revParse(`${ref}^{commit}`))
    )
  }
  // Unexpected
Author	SHA1	Message	Date
Mark Vander Stel	5e544b204a	Merge `1d3fa26c9e` into `85e6279cec`	2025-01-17 13:38:04 -05:00
Josh Gross	85e6279cec	Adjust positioning of user email note and permissions heading (#2044 ) Some checks failed CodeQL / Analyze (push) Has been cancelled Details Licensed / Check licenses (push) Has been cancelled Details Build and Test / build (push) Has been cancelled Details Build and Test / test (macos-latest) (push) Has been cancelled Details Build and Test / test (ubuntu-latest) (push) Has been cancelled Details Build and Test / test (windows-latest) (push) Has been cancelled Details Build and Test / test-proxy (push) Has been cancelled Details Build and Test / test-bypass-proxy (push) Has been cancelled Details Build and Test / test-git-container (push) Has been cancelled Details Build and Test / test-output (push) Has been cancelled Details	2025-01-16 15:56:18 -05:00
Ben Wells	009b9ae9e4	Documentation update - add recommended permissions to Readme (#2043 ) * Update README.md * Update README.md Co-authored-by: Josh Gross <joshmgross@github.com> --------- Co-authored-by: Josh Gross <joshmgross@github.com>	2025-01-16 14:14:48 -05:00
Mark Vander Stel	1d3fa26c9e	Fix checkout of annotated tag loosing annotation 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 #290 Closes #697	2023-10-06 12:42:43 -04:00