No tags are present for this repository using namespace

Hello, first of all thanks for you github actions, it helps a lot but I'm struggling to get it working the way I expect.

I'm using namespace as a suffix to tag and release. Here is my way of working:

A dev environment, each push to develop branch will trigger a deployment and use this action to set correct version in package.json files.
A qa environment, each manual deployment to this env will trigger a deployment and use this action to set correct version in package.json files and at the end will tag using version given by the action. (like v0.1.0-develop)
A staging environment, each push to master/main branch will trigger a deployment and do the same thing than dev env.
A prod environment, same than QA but this time, it will tag an release like v0.1.0-master

      - name: Generate the right version using semantic commit and semantic versionning
        id: version
        uses: paulhatch/semantic-version@v5.2.1
        with:
          namespace: ${{ github.ref_name }}
          major_pattern: '${{ vars.GIT_SEMANTIC_VERSION_MAJOR_PATTERN }}'
          minor_pattern: '${{ vars.GIT_SEMANTIC_VERSION_MINOR_PATTERN }}'
          debug: true

debug:

    "commands": [
        {
            "command": "git",
            "args": [
                "rev-list",
                "-n1",
                "--all"
            ],
            "output": "57bfa3439049e42c2979a4679838b81e6d034fdf\n",
            "stderr": "",
            "error": null
        },
        {
            "command": "git",
            "args": [
                "rev-parse",
                "HEAD"
            ],
            "output": "57bfa3439049e42c2979a4679838b81e6d034fdf\n",
            "stderr": "",
            "error": null
        },
        {
            "command": "git tag --points-at 57bfa3439049e42c2979a4679838b81e6d034fdf v*[0-9].*[0-9].*[0-9]-develop",
            "args": [],
            "output": "",
            "stderr": "",
            "error": null
        },
        {
            "command": "git for-each-ref --sort=-v:*refname --format=%(refname:short) --merged=57bfa3439049e42c2979a4679838b81e6d034fdf refs/tags/v*[0-9].*[0-9].*[0-9]-develop",
            "args": [],
            "output": "",
            "stderr": "",
            "error": null
        },

If I execute these commands locally, it will output nothing, removing the merged git sha from the command is giving me results: How do you determine the git sha used in the merged ? I don't get it. My last commit have not been part of a tag yet.

$ git for-each-ref --sort=-v:*refname  refs/tags/v*[0-9].*[0-9].*[0-9]-develop
25bd8fb4ff61927b045e200d67ead7d542ca47a2 commit refs/tags/v0.1.1-develop
de078b386c5dd269d9dd792a217c06a56c9c846d commit refs/tags/v0.1.0-develop

Or am I doing something wrong ?

Can you check the checkout state of your build? It needs to include the history at least up to the last version, so set fetch depth to zero to pull full history or at least a number higher than the maximum number of commits you'll ever make between versions.

The first command is just used to check for an empty repository, if nothing is returned the action short-circuits there and returns an empty result.

The second command is resolving the current commit. No issues here either, assuming this hash is the one you are expecting.

The third command is checking if the current commit is itself tagged, as these are handled differently. So far no issues based on your tag list since neither of these match the tag indicated as the current commit in earlier commands.

The next command is one of the two key commands, this is trying to find the most recent tag that has been merged into the current head. This tag would normally then be used to determine the previous version and in conjunction with the current commit to get a list of commits to determine what the current implied version is. The debug info indicates there are no tags matching the expected pattern that are ancestors of the previous commit, while the list you provided shows two. The list is cut off after this, but if it is empty perhaps you haven't pulled the necessary history into the action during the checkout step. Besides that, the last tag needs to be an ancestor reachable from the current commit to be counted, so some random tag on a different branch will be ignored here.

Based on your description of your process I would guess that you are tagging commits (e.g. the package.json updates) which are not merged into the other branches. If that's the case you could fix this by changing the commit that you tag to make sure it is one on the branch or making sure that the commit is merged, but I'd really recommend a different approach:

This action was specifically designed originally because I didn't want to store the version in the repo and didn't want extra commits just to set a version. When setting up builds I always use the version from the build, then use a tool like jq or yq to update config files and pass in the version as an argument to whatever build tool I'm using at the time of the build. In this way the repo never includes the version. This works very well for me on a wide variety of project types, you may find it easier than trying to add commits to the repo.

Otherwise you need to be able to run this command and get a tag for the expected version:

git for-each-ref --sort=-v:*refname --format=%(refname:short) --merged=57bfa3439049e42c2979a4679838b81e6d034fdf refs/tags/v*[0-9].*[0-9].*[0-9]-develop

Yes I'm using fetch-depth: 0

      - uses: actions/checkout@v3 # checkout code
        with:
          fetch-depth: 0

But I digged a little bit today and I think I understood the issue by reviewing the git commit tree entirely. I've made few mistakes when merging develop => master by squashing commits (and did something nasty to develop branch afterward). So it look like the taggued commit is actually not retrieved correctly and do not match the one from the latest tag. Thus resulting into returning nothing.

If I follow you right, either I need to add an extra bump version commit and push to develop/master branch before tagging or I need to get rid of the substitution done right ? I surely can do this extra commit. I'll try few things and get back to you.

Nonetheless, thanks for the clear explanation and maybe I'll end up doing it like you suggested.

You just need to make sure that the history of branch/commit you are on includes the tag you expect to derived the version from, so if you're adding commits during the build, they need to be pushed/merged. Though as I said I much prefer not to include the version in the repo at all and set everything during the build using the version obtained from this version action. This is always going to be simpler because you need to do the same automation either way to set the version, in this case you're just doing it before the build and omitting the commit/push/merge step. Also you would need to figure out how to ignore that subsequent commit, otherwise you'll be in an endless loop of builds trigger by version bump commits.

Btw, if you do end up creating and pushing commits in the build, I'd suggest setting the concurrency property on the job to prevent clashes from multiple jobs running simultaneously.

Quick update:

I've managed to create tags manually to start fresh from the commits tree on develop and master branches. As of now, I'm not pushing commits that substitute version in package.json and I wrote in the pipeline a way to run it from a tag and do the substitution based on the tag. This way, I can avoid creating commits only to bump versions.

It's now working perfectly the way I want it to work.

Thanks @PaulHatch

PaulHatch / semantic-version

No tags are present for this repository using namespace #118