<p>A changelog is handy as one will see what changes reside in a certain release. A couple of months ago one of my tools was not working anymore. By consulting the Changelog it was possible to find the issue quite fast. Examples:</p>
<ul>
<li><a href="https://github.com/030/n3dr/blob/master/CHANGELOG.md" rel="nofollow noreferrer">https://github.com/030/n3dr/blob/master/CHANGELOG.md</a></li>
<li><a href="https://github.com/030/dip/blob/master/CHANGELOG.md" rel="nofollow noreferrer">https://github.com/030/dip/blob/master/CHANGELOG.md</a></li>
</ul>
<p>By creating the Changelog manually, one really has to think what kind of changes were applied to an app. It is also possible to this automatically, but then the commit messages have to be very clear and lean to prevent unclarity.</p>
<p>The changelog itself makes it possible to click on a version and to compare it with a previous one. It facilitates to debug issues in an App when changes were applied.</p>
<p>If one would create a release for every merge then it is possible that there would be a huge number of releases. I have worked in a company where some developers were merging each individual commit to the main branch. Result: 10 releases a day and an artifact repository disk that had to be increased every week. I spoke to the particular devs and they did not see the issue and my CTO did not see the issue as well. At a certain point we decided to remove the automatic release step from the pipeline. Now the PO had to create a release that contained multiple commits. Once a tag was created manually the release pipeline was started and a release was created. Since then we had to increase the disk size only once every quarter.</p>

CC BY-SA 4.0
2021-09-28T11:27:13.800Z
Thanks for your time, but it's not what I asked :)
I would like to know what is the benefit of "Creating a tag manually to run a release pipeline (including the changelog)" instead of automate the whole process (e.g: if a PR is merged on master, so it automaticaly create the release)
benCat
CC BY-SA 4.0
2021-09-30T05:51:08.500Z
Ok. I added another paragraph.
030
CC BY-SA 4.0
2021-09-30T21:43:45.520Z
That's exactly what I wanted, thanks a lot for taking this time for me :)
I let the question opened to get more point of view but yours seams to be coherent. Thank you again!
benCat
CC BY-SA 4.0
2021-10-06T20:48:15.303Z
Try to make use of GitVersion with your tagging so that it will generate semantic versioning and environmental variables that you can use in your CI/CD pipeline workflow.  For example, when a check-in is done then a build is done and maybe an automated deployment.  When the same repo and branch is tagged then it does all of the regular things but then a docker container can be created by evaluating of the build was done from a regular commit or from being tagged.
Antebios
CC BY-SA 4.0
2021-09-26T18:47:06.877Z
2021-09-30T05:50:44.527Z
2021-09-30T05:50:44.527Z
030
<p>I work on a new CICD, replacing Jenkins-X 2 by GitHub Actions.</p>
<p>After seeing a lot of actions to create a release + changelog, I found that a lot of them are trigger by a tag on a commit to launch the workflow.</p>
<p>For now, I create a new release on every push on master (merged pr), with a version tag (v1.0.0), via conventional commit.</p>
<p>What is the benefit for me or Lead team to manually create a tag to generate a new release + changelog ?</p>
<p>What is the logic behind that ?</p>
<p><strong>EDIT:</strong>
I would like to know what is the benefit of &quot;Creating a tag manually to run a release pipeline (including the changelog)&quot; instead of automate the whole process (e.g: if a PR is merged on master, so it automaticaly create the release)</p>

<cicd><release><github-actions>
Why should I tag a commit to create a release?
benCat
# Why should I tag a commit to create a release?

(Asked by: username_0 on 2021-09-21)

I work on a new CICD, replacing Jenkins-X 2 by GitHub Actions.

After seeing a lot of actions to create a release + changelog, I found that a lot of them are trigger by a tag on a commit to launch the workflow.

For now, I create a new release on every push on master (merged pr), with a version tag (v1.0.0), via conventional commit.

What is the benefit for me or Lead team to manually create a tag to generate a new release + changelog ?

What is the logic behind that ?

**EDIT:**
I would like to know what is the benefit of "Creating a tag manually to run a release pipeline (including the changelog)" instead of automate the whole process (e.g: if a PR is merged on master, so it automaticaly create the release)

**Tags:** cicd, release, github-actions


---

## 1 answers

### Answer by username_1 on 2021-09-26. Score: 1

A changelog is handy as one will see what changes reside in a certain release. A couple of months ago one of my tools was not working anymore. By consulting the Changelog it was possible to find the issue quite fast. Examples:

* <https://github.com/username_1/n3dr/blob/master/CHANGELOG.md>
* <https://github.com/username_1/dip/blob/master/CHANGELOG.md>

By creating the Changelog manually, one really has to think what kind of changes were applied to an app. It is also possible to this automatically, but then the commit messages have to be very clear and lean to prevent unclarity.

The changelog itself makes it possible to click on a version and to compare it with a previous one. It facilitates to debug issues in an App when changes were applied.

If one would create a release for every merge then it is possible that there would be a huge number of releases. I have worked in a company where some developers were merging each individual commit to the main branch. Result: 10 releases a day and an artifact repository disk that had to be increased every week. I spoke to the particular devs and they did not see the issue and my CTO did not see the issue as well. At a certain point we decided to remove the automatic release step from the pipeline. Now the PO had to create a release that contained multiple commits. Once a tag was created manually the release pipeline was started and a release was created. Since then we had to increase the disk size only once every quarter.

> **Comments:**
> **username_0**: Thanks for your time, but it's not what I asked :) I would like to know what is the benefit of "Creating a tag manually to run a release pipeline (including the changelog)" instead of automate the whole process (e.g: if a PR is merged on master, so it automaticaly create the release)  
> **username_1**: Ok. I added another paragraph.  
> **username_0**: That's exactly what I wanted, thanks a lot for taking this time for me :) I let the question opened to get more point of view but yours seams to be coherent. Thank you again!  
> **username_2**: Try to make use of GitVersion with your tagging so that it will generate semantic versioning and environmental variables that you can use in your CI/CD pipeline workflow.  For example, when a check-in is done then a build is done and maybe an automated deployment.  When the same repo and branch is tagged then it does all of the regular things but then a docker container can be created by evaluating of the build was done from a regular commit or from being tagged.  

---

