Goreleaser issues when tag is pushed from a GitHub Action

[brpaz]

Hello.
I am trying to use GoReleaser an application

The official GitHub Actions guide of Goreleaser shows having a "release" workflow triggered when a new tag is pushed to GitHub. Unfortunaly this doesnt seem to work on the tag is being pushed by another workflow, which is my case. see.

So I decided a different approach and have a single workflow file. But now when I run go releaser I get the following error:

fatal: no tag exactly matches '88cdc2e1d4faa96bb541f737e69164cb89071d74'
/bin/tar xz --warning=no-unknown-keyword -C /home/runner/work/_temp/b2d237e5-7149-477c-b279-d868d46c6076 -f /tmp/goreleaser-rNRERC/goreleaser_Linux_x86_64.tar.gz
⚠️ No tag found for commit 88cdc2e. Snapshot forced

I think this happens because the commit the pipeline is being run is not the same as the tag because the tag was created from the same workflow.

Is there any way to force the release and specifying the correct tag?

Here is my full Workflow: https://github.com/brpaz/do-snapshot-pruner/edit/master/.github/workflows/ci.yaml

Thank you.

[brpaz]

I managed to solve this by manually do a git checkout of the latest tag. Still this workflow needs to be improved.

[caarlos0]

this seems to be a limitation on actions... not sure what we could do here...

cc/ @crazy-max any ideas?

[crazy-max]

Hi @brpaz,

When a workflow is triggered on push event the resulting commit id is attached to it:

Referenced commit id for this workflow is a211dc7

But if you push changes, the workflow is "broken":

Work tree changed from a211dc7 to 754a555 in the Tag Release job and so Goreleaser job is not aware of this change (remember that jobs are self-contained and so not aware of other ones):

As you can see goreleaser action checks out a211dc7.

How can we solve that? Well as you may know, GoReleaser is tightly closed to Git. What you can do is merged your Tag Release job in your goreleaser job:

  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Unshallow
        run: git fetch --prune --unshallow
      - name: Set up Go
        uses: actions/setup-go@v1
        with:
          go-version: 1.14.x
      - uses: actions/setup-node@v1
        if: github.ref == 'refs/heads/master' && github.event_name == 'push'
        with:
          node-version: "12.x"
      - name: Bump version and Generate Changelog
        if: github.ref == 'refs/heads/master' && github.event_name == 'push'
        run: |
          git config user.name "$(git --no-pager log --format=format:'%an' -n 1)"
          git config user.email "$(git --no-pager log --format=format:'%ae' -n 1)"
          npx standard-version -no-verify
          git remote rm origin
          git remote add origin https://$GITHUB_ACTOR:[email protected]/$GITHUB_REPOSITORY.git
          git push --follow-tags origin HEAD:master
        env:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
          GITHUB_ACTOR: ${{github.actor}}
          GITHUB_REPOSITORY: ${{github.repository}}
      - name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v1
        with:
          version: latest
          args: release --rm-dist --release-notes CHANGELOG.md
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I think this is the right way to proceed in your case even though I am absolutely not a fan of this "GitFlow". For me it's up to the user to decide how to create the tag and not to the CI to automatically "bump" it, but that's another matter ;)

See this example to trigger a build on push tags event.

You should also not mixed up actions/checkout versions in your workflow.

[brpaz]

Ah, thanks for the detailed explanation. I think it could work line that. Thank you.

Regarding the Git Flow, yes I agree in general, but for this particular project and other small projects, I want it to be the most automated possible and don't have to worry about manual creating releases.