Q: could this also move the release tag along with the new commit?

[clemblanco]

The commit this will effectively add to master or main will have the latest changes for the CHANGELOG.md file.

Awesome stuff. However, correct me if I'm wrong, but the tag will remain on the original n-1 commit, before the CHANGELOG.md file gets updated, right?

Is there a way to move the tag along too?

Many thanks 🙏

[stefanzweifel]

(I've migrated this issue to discussion as it's not really a bug of changelog-updater-action)

---

However, correct me if I'm wrong, but the tag will remain on the original n-1 commit, before the CHANGELOG.md file gets updated, right?

Correct. The example shown in the README will create a commit which is not "inside" a tag.
However, changelog-updater-action doesn't create and push the commit. That is done by the git-auto-commit-action.

Is there a way to move the tag along too?

Technically possible, but I think this will lead a lot of side effects.
Let's imagine …

• You create a new tag in your terminal, push this tag to GitHub and create a release through their UI.
• The Actions Workflow is triggered and updates CHANGELOG.md

Now, how do we commit this change so that it's incorporated in the tag?

• You could amend the last commit. This will rewrite the git history and the tag, you've just created and published a release for, is gone (I think).
• (I think) you would then have to force push the just created commit back to GitHub. Otherwise Github would/could reject the commit as the last commit it knows of, doesn't update the CHANGELOG
• Your previously created release could be gone, as the commit/sha to the associated tag changed. So you would then have to create another release, which then triggers the Actions workflow, which updates the changelog, which changes the git-history …

I think you can see that this could lead to some weird behaviour.
Also, while the workflow is run, commits made to main could get lost if the commit is force pushed.

---

These are just my thoughts though.

I haven't tested this in a real example application. Maybe it could work if you're using --amend and --force.
The git-auto-commit-Action is quite flexible. Something like this should work:

- name: Commit updated CHANGELOG
  uses: stefanzweifel/git-auto-commit-action@v4
  with:
    branch: ${{ github.event.release.target_commitish }}
    commit_message: Update CHANGELOG
    file_pattern: CHANGELOG.md
    commit_options: '--amend --signoff'
    push_options: '--force'
    skip_fetch: true

(But use with care. I'm not responsible if you're losing valuable commits in your project)

[clemblanco]

Interesting. Thanks for the answer. I was just thinking that the source code distributed to any package manager (like Packagist) would not included the updated CHANGELOG.md (if included) as the tag will point to the n-1 commit. Not sure of a lot of people actually would actually use the file there much. Maybe I just need to avoid distributing it...

…

On Tue, 22 Feb 2022, 20:25 Stefan Zweifel, ***@***.***> wrote: (I've migrated this issue to discussion as it's not really a bug of changelog-updater-action) ------------------------------ However, correct me if I'm wrong, but the tag will remain on the original n-1 commit, before the CHANGELOG.md file gets updated, right? Correct. The example shown in the README will create a commit which is not "inside" a tag. However, changelog-updater-action doesn't create and push the commit. That is done by the git-auto-commit <https://github.com/stefanzweifel/git-auto-commit-action>-action. Is there a way to move the tag along too? Technically possible, but I think this will lead a lot of side effects. Let's imagine … - You create a new tag in your terminal, push this tag to GitHub and create a release through their UI. - The Actions Workflow is triggered and updates CHANGELOG.md Now, how do we commit this change so that it's incorporated in the tag? - You could amend <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---amend> the last commit. This will rewrite the git history and the tag, you've just created and published a release for, is gone (I think). - (I think) you would then have to force push <https://git-scm.com/docs/git-push#Documentation/git-push.txt---force> the just created commit back to GitHub. Otherwise Github would/could reject the commit as the last commit it knows of, doesn't update the CHANGELOG - Your previously created release could be gone, as the commit/sha to the associated tag changed. So you would then have to create another release, which then triggers the Actions workflow, which updates the changelog, which changes the git-history … I think you can see that this could lead to some weird behaviour. Also, while the workflow is run, commits made to main could get lost if the commit is force pushed. ------------------------------ These are just my thoughts though. I haven't tested this in a real example application. Maybe it could work if you're using --amend and --force. The git-auto-commit-Action is quite flexible. Something like this should work: - name: Commit updated CHANGELOG uses: ***@***.*** with: branch: ${{ github.event.release.target_commitish }} commit_message: Update CHANGELOG file_pattern: CHANGELOG.md commit_options: '--amend --signoff' push_options: '--force' skip_fetch: true (But use with care. I'm not responsible if you're losing valuable commits in your project) — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFDGA2AMATQKD6HWC6ICKDU4PWM5ANCNFSM5PCN65EQ> . You are receiving this because you authored the thread.Message ID: <stefanzweifel/changelog-updater-action/repo-discussions/11/comments/2231717 @github.com>

[stefanzweifel]

Totally valid point and concern. I thought about this before too, but couldn't come up with a good solution.

Feel free to experiment and share your solution.

[stefanzweifel]

Quick follow up: I've recently released a couple of updates to make it easier to use the Action in different scenarios.

Another user shared how he is using this Action to create a release manually.

1. Trigger Action through workflow_dispatch
2. Build the artifacts of the project
3. Update the changelog with release notes already present in the CHANGELOG.md (content between Unreleased heading and previous release)
4. Commit and tag changes
5. Generate new GitHub release with links to CHANGELOG and compare URLs.

It's a bit more involved, but that way the changed CHANGELOG is included in the Git commit. Maybe that's something you can use in your projects too.

Links:

• Support workflow for manually crafted changelog #12
• https://github.com/axkr/symja_android_library/blob/b371b64b0893e20a738cf4db23e3a0fafa679b6b/.github/workflows/maven-perform-release.yml