Possible regresion on Ubuntu agents for git tag command

[macchmie3]

Description

Hi,

We noticed a problem with Git client on Ubuntu-latest on Thrusday 23.01.2025. We have a .yml file for deployment and we didnt change the file or the infrastructure of our codebase / Azure cloud.

Basically out commits have a single git-tag and we need to read it. After the agent update the git tag command stopped outputing the tags, no error is raised. At the same time the same code on our custom windows build agents still works.

The sample code that stopped working:

jobs:
  deploy:
    runs-on: ubuntu-latest #Azure CLI works only on Linux
    permissions:
      id-token: write
      contents: write
   steps:
        - name: Download artifact from build job
          uses: actions/download-artifact@v4
          with:
            name: ${{ inputs.artifact-name }}
            fetch-tags: true
        - name: Get existing version tag
          id: get-existing-tag
          shell: bash
          run: |
            echo "EXISTING=$( (git tag --points-at ${{ inputs.commit-sha }}) | head -1)" >> $GITHUB_OUTPUT
        - run: echo Updating tag for ${{ steps.get-existing-tag.outputs.EXISTING }}
          shell: bash

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

20250120.5.0

Is it regression?

20250105.1.0

Expected behavior

git tag --points-at ${{ inputs.commit-sha }} should output the name of existing tag

Actual behavior

Nothing is seen in output

Repro steps

Create a workflow with 2 parts - 1st adds a tag to a commit, 2nd that tries to read the commit.

[RaviAkshintala]

Hi @macchmie3 Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigating.

[RaviAkshintala]

Hi @macchmie3 I have followed your steps and can successfully read the output. Attached below is the workflow file for your review, along with the corresponding output. Thanks.

jobs:
  add-tag:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Add tag to commit
        run: |
          TAG_NAME="v1.0.$(date +%Y%m%d%H%M%S)"
          git tag $TAG_NAME
          git push origin $TAG_NAME
  read-tag:
    runs-on: ubuntu-latest
    needs: add-tag
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          fetch-tags: true

      - name: Get existing version tag
        id: get-existing-tag
        run: |
          echo "EXISTING=$(git tag --points-at HEAD | head -1)" >> $GITHUB_OUTPUT
      - name: Output tag
        run: echo "Tag:${{ steps.get-existing-tag.outputs.EXISTING }}"

FYI:
https://github.com/RaviAkshintala/runner-images/actions/runs/13024377395/job/36330910333#step:4:5

[macchmie3]

Hi @RaviAkshintala

Thanks for your answer! I see that I see the issue at the checkout step actually so you can disregard the step Get existing version tag.

Could you please run your sample with fetch-depth: 1 - which is default depth? When I fetch whole history I see the tags correctly (with a lot of overhead of course). Runs from working version 20250105.1.0 did output the checkout as:

Fetching the repository
  /usr/bin/git -c protocol.version=2 fetch --prune --no-recurse-submodules --depth=1 origin +<redacted_commit_sha>:refs/remotes/origin/master
  From <redacted_private_repo_adress>
   * [new ref]       redacted_commit_sha -> origin/master
   * [new tag]        redacted_tag_name  -> redacted_tag_name

[macchmie3]

@RaviAkshintala

I thinks that's the root cause of the problem: actions/checkout#2041