{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":701444604,"defaultBranch":"main","name":"actions-checkout","ownerLogin":"Rycieos","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-10-06T16:38:51.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/8375571?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1696610492.0","currentOid":""},"activityList":{"items":[{"before":"330bbabc4a1fa4a8bd4bb5f29398fdb3adf8b6df","after":"1d3fa26c9e7d4ecfa3e57f92ce378f166e84fc3f","ref":"refs/heads/bugfix/annotated-tag","pushedAt":"2023-10-06T16:57:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"Rycieos","name":"Mark Vander Stel","path":"/Rycieos","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8375571?s=80&v=4"},"commit":{"message":"Fix checkout of annotated tag loosing annotation\n\nCurrently, a check is done after fetch to ensure that the repo state has\nnot changed since the workflow was triggered. This check will reset the\ncheckout to the commit that triggered the workflow, even if the branch\nor tag has moved since.\n\nThe issue is that the check currently sees what \"object\" the ref points\nto. For an annotated tag, that is the annotation, not the commit. This\nmeans the check always fails for annotated tags, and they are reset to\nthe commit, losing the annotation. Losing the annotation can be fatal,\nas `git describe` will only match annotated tags.\n\nThe fix is simple: check if the tag points at the right commit, ignoring\nany other type of object. This is done with the <rev>^{commit} syntax.\n\nFrom the git-rev-parse docs:\n> <rev>^{<type>}, e.g. v0.99.8^{commit}\n>  A suffix ^ followed by an object type name enclosed in brace pair\n>  means dereference the object at <rev> recursively until an object of\n>  type <type> is found or the object cannot be dereferenced anymore (in\n>  which case, barf). For example, if <rev> is a commit-ish,\n>  <rev>^{commit} describes the corresponding commit object. Similarly,\n>  if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree\n>  object.  <rev>^0 is a short-hand for <rev>^{commit}.\n\nIf the check still fails, we will still reset the tag to the commit,\nlosing the annotation. However, there is no way to truly recover in this\nsitutation, as GitHub does not capture the annotation on workflow start,\nand since the history has changed, we can not trust the new tag to\ncontain the same data as it did before.\n\nFixes #290\nCloses #697","shortMessageHtmlLink":"Fix checkout of annotated tag loosing annotation"}},{"before":null,"after":"330bbabc4a1fa4a8bd4bb5f29398fdb3adf8b6df","ref":"refs/heads/bugfix/annotated-tag","pushedAt":"2023-10-06T16:41:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"Rycieos","name":"Mark Vander Stel","path":"/Rycieos","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8375571?s=80&v=4"},"commit":{"message":"Fix checkout of annotated tag loosing annotation\n\nCurrently, a check is done after fetch to ensure that the repo state has\nnot changed since the workflow was triggered. This check will reset the\ncheckout to the commit that triggered the workflow, even if the branch\nor tag has moved since.\n\nThe issue is that the check currently sees what \"object\" the ref points\nto. For an annotated tag, that is the annotation, not the commit. This\nmeans the check always fails for annotated tags, and they are reset to\nthe commit, losing the annotation. Losing the annotation can be fatal,\nas `git describe` will only match annotated tags.\n\nThe fix is simple: check if the tag points at the right commit, ignoring\nany other type of object. This is done with the <rev>^{commit} syntax.\n\nFrom the git-rev-parse docs:\n> <rev>^{<type>}, e.g. v0.99.8^{commit}\n>  A suffix ^ followed by an object type name enclosed in brace pair\n>  means dereference the object at <rev> recursively until an object of\n>  type <type> is found or the object cannot be dereferenced anymore (in\n>  which case, barf). For example, if <rev> is a commit-ish,\n>  <rev>^{commit} describes the corresponding commit object. Similarly,\n>  if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree\n>  object.  <rev>^0 is a short-hand for <rev>^{commit}.\n\nIf the check still fails, we will still reset the tag to the commit,\nlosing the annotation. However, there is no way to truly recover in this\nsitutation, as GitHub does not capture the annotation on workflow start,\nand since the history has changed, we can not trust the new tag to\ncontain the same data as it did before.","shortMessageHtmlLink":"Fix checkout of annotated tag loosing annotation"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"startCursor":"Y3Vyc29yOnYyOpK7MjAyMy0xMC0wNlQxNjo1NzoxOS4wMDAwMDBazwAAAAORPri8","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0xMC0wNlQxNjo0MTozMi4wMDAwMDBazwAAAAORPDTZ"}},"title":"Activity · Rycieos/actions-checkout"}