Error: "fatal: not a git repository (or any of the parent directories): .git"

[KonradHoeffner]

In https://github.com/annosaxfdm/ontology/actions/runs/11439151403/job/31822224741, I get a fatal error:

Run mikepenz/release-changelog-builder-action@v5
📘 Reading input values
ℹ️ Retrieved configuration via 'configurationJson'.
ℹ️ Running in COMMIT mode.
🔖 Resolve tags
ℹ️ Found 5 (fetching max: 200) tags from the GitHub API for annosaxfdm/ontology
🔖 Resolved current tag (24.10) from the 'github.context.ref'
ℹ️ Only one tag found for the given repository. Usually this is the case for the initial release.
/usr/bin/git rev-list --max-parents=0 HEAD
fatal: not a git repository (or any of the parent directories): .git
Warning: ⚠️ No tag found for the given repository
Error: 💥 Unable to retrieve previous tag given

The workflow starts as follows:

name: Release
on:
  push:
    tags: '[2-9][0-9]\.[0-9][0-9]'
jobs:
  create-release:
    name: Create release
    runs-on: ubuntu-latest
    outputs:
      upload_url: ${{ steps.create-release.outputs.upload_url }}
    steps:
      - name: Changelog
        id: changelog
        uses: mikepenz/release-changelog-builder-action@v5
        with:
          mode: "COMMIT"
          configurationJson: |
            {
              "pr_template": "- #{{TITLE}}",
              "template": "#{{UNCATEGORIZED}}"
            }

      - name: Checkout code
        uses: actions/checkout@v4

[...]

There are 5 tags, like "24.04" or "24.02", but they are not picked up.
I don't know if it is related, but before the warning about the missing tags there is " /usr/bin/git rev-list --max-parents=0 HEAD
fatal: not a git repository (or any of the parent directories): .git" and I wonder if that is causing the error.

[mikepenz]

This error appears when the action is run on a repo which is a shallow checkout (without tags) or not a git repo, if the action can't resolve the prior tag based on the API or if it wasn't passed.

So the error itself isn't really a problem in that case. as based on your example, you run the action without a checkout at all. so it's expected.

[KonradHoeffner]

Ah, the checkout is below that as I was looking at the examples in the README and there is no checkout before it either. Also, it worked previously so I thought this is working as intended.

I will try it with the steps switched out, so that the checkout comes first.

[mikepenz]

To be specific. A checkout is not required, if the action has alternative means to get the from and to tag. it really depends on the usecase.

Falling back to checking the current git state is only another mechanism to identify the current tag.

usually the toTag is given via the CI trigger, and the fromTag is then resolved from the GitHub API, based on finding the tag next.

I feel like your overall problem comes from here: #1383
I haven't yet looked deeper into it, on why you wouldn't be able to use the string sorting anymore.

Given YEAR.MONTH.DAY should properly sort in all cases.

[KonradHoeffner]

Thank you, moving the checkout in front of the changelog step has fixed that error. However I still do not understand why it first finds 5 tags and then in the next step it does not find any other tags anymore even though I have not specified any filter.
The tags are 23.09, 23.11, 24.02, 24.04 and 24.10.

🔖 Resolve tags
ℹ️ Found 5 (fetching max: 200) tags from the GitHub API for annosaxfdm/ontology
🔖 Resolved current tag (24.10) from the 'github.context.ref'
ℹ️ Only one tag found for the given repository. Usually this is the case for the initial release.
/usr/bin/git rev-list --max-parents=0 HEAD
08f0048871c92167861975a496e08d167ed19bbd
🔖 Resolved initial commit (08f0048871c92167861975a496e08d167ed19bbd) from 'git rev-list --max-parents=0 HEAD'
🔖 Resolved previous tag (08f0048871c92167861975a496e08d167ed19bbd) from the tags git API

[mikepenz]

Based on this ticket: #1383 (comment) I assume you also have a filter on the tags?

Or in that case you have removed it?

[KonradHoeffner]

I have currently removed the filter as it was not working properly anyways.
Here is my complete current workflow:

name: Release
on:
  push:
    tags: '[2-9][0-9]\.[0-9][0-9]'
jobs:
  create-release:
    name: Create release
    runs-on: ubuntu-latest
    outputs:
      upload_url: ${{ steps.create-release.outputs.upload_url }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Changelog
        id: changelog
        uses: mikepenz/release-changelog-builder-action@v5
        with:
          mode: "COMMIT"
          configurationJson: |
            {
              "pr_template": "- #{{TITLE}}",
              "template": "#{{UNCATEGORIZED}}",
            }

      - name: Install dependencies
        run: sudo apt-get install -y raptor2-utils

      - name: Build
        id: build
        run: |
             scripts/combine | tee $GITHUB_STEP_SUMMARY
             scripts/olsworkaround
             echo 'summary<<EOF' >> $GITHUB_OUTPUT
             cat ${GITHUB_STEP_SUMMARY} >> $GITHUB_OUTPUT
             echo 'EOF' >> $GITHUB_OUTPUT

      - name: Create Release
        id: create-release
        uses: softprops/action-gh-release@v2
        with:
          body: |
                ${{ steps.build.outputs.summary }}
                ${{ steps.changelog.outputs.changelog }}
          files: |
            dist/anno.ttl
            dist/anno-ols.ttl

[mikepenz]

oh but you also removed the logic to enable the sort based tag handling. By default semver is used, which filters out all the tags you have. given none are semver compliant.

release-changelog-builder-action/src/configuration.ts

Line 103 in 69817ff

method: 'semver', // defines which method to use, by default it will use `semver` (dropping all non-matching tags). Alternative `sort` is also available.

you wanna use sort:

release-changelog-builder-action/src/pr-collector/tags.ts

Line 245 in 69817ff

if (tagResolver.method === 'sort') {

[KonradHoeffner]

But isn't 24.02 a valid semver version? For example Ubuntu Linux has been using that for a long time.

[mikepenz]

Based on my understanding of semver it is not.

See: https://jubianchi.github.io/semver-check/#/version/24.02

However 24.2.1 is

[KonradHoeffner]

Ah, you are right. However in case anyone else is making the same mistake as I did, it would be helpful to document in the README that only valid semver tags following major.minor.patch will be picked up.
If you agree, I could create a pull request clarifying that.

[mikepenz]

There's already this note:

Could probably expanded by adding non semver tags will not be considered