requarks / changelog-action

GitHub Action to generate changelog from conventional commits
MIT License
128 stars 41 forks source link

How to prevent workflow failing of the very first release (when no previous tag exists)? #42

Open gremo opened 1 year ago

gremo commented 1 year ago

I've read the note in the documentation:

You must already have 2 tags in your repository (1 previous tag + the current latest tag triggering the job). The job will exit with an error if it can't find the previous tag!

My question is how to prevent the workflow failing caused when no previous tag exists. I think that this should be documented too, at least with some code snippers. Because on a brand new project, this is going to 100% fail for obvious reasons.

Of course one can:

  1. Create the first tag and push it
  2. Manually create a the first release based on the tag above
  3. Add the workflow

... but this is very incovenient.

name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Update CHANGELOG
        id: changelog
        uses: requarks/changelog-action@v1
        with:
          token: ${{ github.token }}
          tag: ${{ github.ref_name }}

      - name: Create Release
        uses: ncipollo/release-action@v1
        with:
          allowUpdates: true
          makeLatest: true
          body: ${{ steps.changelog.outputs.changes }}
          token: ${{ github.token }}

      - name: Commit CHANGELOG.md
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          branch: main
          commit_message: 'chore(docs): Update CHANGELOG.md for ${{ github.ref_name }} [ci skip]'
          file_pattern: CHANGELOG.md
CaueP commented 9 months ago

I'm facing the same issue.

What if when it's the first tag (there is no previous tag) it considers the whole history to build a change log? Instead of using a previous tag, it could look at the first commit and build the changelog from it in this initial release.

elondaits commented 8 months ago

I agree. Also, this is a case where it could and I think should fail silently (if no other solution is possible). An empty changelog is not a big deal, but a failed first release is.

If we are to handle it ourselves (through conditional execution of the steps, default, etc.) this would make our workflow more complex but only to handle the first release... it doesn't make practical sense.