Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetch-tags is not working according to the docs with v4 #1781

Open
64J0 opened this issue Jun 15, 2024 · 6 comments · May be fixed by #2039
Open

fetch-tags is not working according to the docs with v4 #1781

64J0 opened this issue Jun 15, 2024 · 6 comments · May be fixed by #2039

Comments

@64J0
Copy link

64J0 commented Jun 15, 2024

Hello, hope you're good. I'm running some experiments in order to build a custom action that demands the tags from the repo. I noticed that it was possible, in theory, just using the fetch-tags: true, but it does not work. I can only get the tags if I use the fetch-depth: 0.

Example workflow:

jobs:
  custom-action:
    runs-on: ubuntu-22.04
    steps:
      - name: Checkout repo
        uses: actions/checkout@v4
        with:
          path: tagaction
          fetch-tags: true
      - name: Try to get the tags
        run: |
          cd tagaction
          git tag --sort -creatordate

The last command (git tag --sort -creatordate) shows nothing in this case.

But, if I use the fetch-depth: 0, it lists correctly the tags from the repository.

@brandonsturgeon
Copy link

brandonsturgeon commented Jun 27, 2024

I'm getting this too. I don't want to set fetch depth to 0.
It looks like git fetch --tags before running my commands works 👍

e: Looks like this still breaks if I use git describe --tags but that might be unrelated.

abxy added a commit to ReVibe-Energy/pyanura that referenced this issue Jul 5, 2024
We should not be required to add this, but fetch-tags: true seems broken.
See actions/checkout#1781 for a second opinion,
and possible resolution.
abxy added a commit to ReVibe-Energy/pyanura that referenced this issue Jul 5, 2024
We should not be required to add this, but fetch-tags: true seems broken.
See actions/checkout#1781 for a second opinion,
and possible resolution.
abxy added a commit to ReVibe-Energy/pyanura that referenced this issue Jul 11, 2024
We should not be required to add this, but fetch-tags: true seems broken.
See actions/checkout#1781 for a second opinion,
and possible resolution.
nwiltsie added a commit to uclahs-cds/tool-create-release that referenced this issue Jul 29, 2024
jnikula added a commit to jnikula/hawkmoth that referenced this issue Sep 7, 2024
checkout@v4 fetch-tags: true does not seem to work as expected
[1]. Version matrix ends up missing the tag for stable:

matrix={"include":[{"ref":"master","name":"dev"},{"ref":"","name":"stable"}]}

Work around this by reverting back to running git fetch --tags manually.

[1] actions/checkout#1781
@nerudaj
Copy link

nerudaj commented Sep 22, 2024

Still an issue.

@guettli
Copy link

guettli commented Oct 2, 2024

The issue looks like this for us:

We are running 4.1.7 and use fetch-depth: 0, fetch-tags: true.

git tag -l lists all tags, except the tags we pushed (and which triggered our GithubAction for releasing).

We use git describe to detect the current git-tag. Since the pushed tag is not visible, our release process fails.

@csteenbock
Copy link

csteenbock commented Dec 2, 2024

Also not working for me. I have fetch-tags: true, and it shows that in the action log, but the git command is not adding --tags like it should:

/opt/homebrew/bin/git -c protocol.version=2 fetch --prune --no-recurse-submodules --depth=1 origin +ab3c37e37b1bb41e6336a1f34d4f75f5706879af:refs/remotes/pull/193/merge

EDIT: You can see that they are not adding --tags in the fetch function here. I tried creating a branch to fix it, but I guess I don't have permission.

@totkeks
Copy link

totkeks commented Jan 4, 2025

I tried creating a branch to fix it, but I guess I don't have permission.

You need to create a fork of the repo first and then make a PR towards the original repo.

andreineculau added a commit to andreineculau/checkout that referenced this issue Jan 14, 2025
@andreineculau andreineculau linked a pull request Jan 14, 2025 that will close this issue
@jakeatoms
Copy link

I'm experiencing something related, wherein I am using fetch-depth: 0 and am getting all tags. The docs state that fetch-tags defaults to false, but it doesn't appear to be working. I get the same behavior even when I explicitly pass fetch-tags: false.

VojtechVitek added a commit to webrpc/webrpc that referenced this issue Feb 4, 2025
VojtechVitek added a commit to webrpc/webrpc that referenced this issue Feb 4, 2025
VojtechVitek added a commit to webrpc/webrpc that referenced this issue Feb 4, 2025
* Upgrade deps

* Upgrade to Go 1.23; support Go 1.20+

* Require Go 1.22+, upgrade deps

* CI: Debug git describe --tags

* Is there a bug in actions/checkout@v4?

actions/checkout#1781

* Fix go.sum

* Improve inferring webrpc-gen version from a Go module
ivoanjo added a commit to DataDog/ruby-dev-builder that referenced this issue Feb 17, 2025
**What does this PR do?**

This PR is a second attempt at adding 3.4-asan builds (first attempt was
ruby#13); this version
is now atop ruby#14 .

It introduces a new "3.4-asan" build, based on the existing asan builds,
but just pointed at the `ruby_3_4` branch.

In ruby#13, we were building
the latest tagged 3.4 release, which I expect would be more stable
than just using `ruby_3_4` (and thus better for my downstream
purposes of "having a build that doesn't fail for non-asan-related
reasons").

Switching between both options is as simple as:

```diff
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 7eb72a8..d7608d9 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -29,6 +29,8 @@ jobs:
       with:
         repository: ruby/ruby
         path: ruby
+        fetch-tags: true
+        fetch-depth: 0 # Workaround for actions/checkout#1781
     - name: Set latest_commit
       id: latest_commit
       working-directory: ruby
@@ -37,7 +39,8 @@ jobs:
       id: latest_commit_3_4_asan
       working-directory: ruby
       run: |
-        git checkout ruby_3_4
+        LATEST_TAG=$(git tag --list | grep -E "v3_4_[0-9]+$" | sort -V | tail -n1)
+        git checkout "$LATEST_TAG"
         echo "commit=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT
     - name: Check if latest commit already built
       uses: actions/github-script@v7
```

I personally prefer building from the tag, but happy to use the
branch option if that's preferrable.

**Motivation:**

The intention of "3.4-stable" is to provide the latest up-to-date
stable Ruby, so that we can reliably use it as a breaking CI step.

As discussed in ruby/setup-ruby#682, the
current ruby-asan builds are a bit of a "sharp edge" when used in CI
because they may break due to changes that are completely unrelated to
asan.

Building asan rubies is a bit awkward still, as e.g. ruby-build and
other version managers don't have support for it, and it requires
very modern versions of specific system tools (e.g. clang).

**Additional Notes:**

In particular, I decided to not touch the logic that determines weather
there's a more recent commit to build or not. This does mean that if
ruby master sees no commits, but there's changes in the 3.4 branch,
this won't be picked up immediately; and it also means that if there's
a new master commit and no change to the 3.4 branch we still rebuild
3.4-asan.

My thinking is that given that ruby#14 added caching already, this approach
keeps things simple.

Let me know if you're not convinced, and I can change that.

**How to test the change?**

I've built this in the downstream fork, and manually downloaded the resulting Ruby and it seems to be in good shape and with asan working fine.

* Successful run: FIXME
* Resulting builds: FIXME
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants