Update release notes if tag exists #97
Assignees
Labels
enhancement
New feature or request
Comments
nipafx
pushed a commit
to junit-pioneer/junit-pioneer
that referenced
this issue
Apr 28, 2021
Shipkit auto-versioning-plugin can detect the version to be released on its own, but it increases the patch versions by number of commits since recent release (hence 1.3.0 ~> 1.3.8), which is not what we want. A feature request for incremental increases was declined.[1] ## Options We hence need to define the version externally. The two main options are: 1. pushing a tag and detecting that from Gradle 2. defining it in the manual GitHub Action[2] and passing it to Gradle We didn't discuss preference as 1. does currently not work with Shipkit because the changelog plugin fails to fill in the GitHub release.[3] ## GitHub Action We went with 2., which requires a slight change to the build and a larger change to the documentation in `CONTRIBUTING.md`. ## `version.properties` file Contrary to what the documentation seems to suggest, the file `version.properties` and the `version` property are always needed, even if the property is specified on the command line. We hence keep the file. In the hope that we don't have to keep updating it, we set a bogus version, though. 🤞🏾 [1] shipkit/shipkit-auto-version#72 [2] https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/ [3] shipkit/shipkit-changelog#97 Closes: #442 PR: #466
|
@shestee, do you want to take a stab at this? |
Yes, I will do it. Thank you for asking! |
|
Sample project: https://github.com/mockitoguy/shipkit-demo |
mockitoguy
pushed a commit
that referenced
this issue
May 26, 2022
This way, users can create releases from GH UI and the CI can still update the release notes. Fixes #97
mockitoguy
pushed a commit
that referenced
this issue
May 26, 2022
This way, users can create releases from GH UI and the CI can still update the release notes. Fixes #97
GrigoriyBeziuk
pushed a commit
to GrigoriyBeziuk/junit-pioneer
that referenced
this issue
Jan 31, 2024
Shipkit auto-versioning-plugin can detect the version to be released on its own, but it increases the patch versions by number of commits since recent release (hence 1.3.0 ~> 1.3.8), which is not what we want. A feature request for incremental increases was declined.[1] ## Options We hence need to define the version externally. The two main options are: 1. pushing a tag and detecting that from Gradle 2. defining it in the manual GitHub Action[2] and passing it to Gradle We didn't discuss preference as 1. does currently not work with Shipkit because the changelog plugin fails to fill in the GitHub release.[3] ## GitHub Action We went with 2., which requires a slight change to the build and a larger change to the documentation in `CONTRIBUTING.md`. ## `version.properties` file Contrary to what the documentation seems to suggest, the file `version.properties` and the `version` property are always needed, even if the property is specified on the command line. We hence keep the file. In the hope that we don't have to keep updating it, we set a bogus version, though. 🤞🏾 [1] shipkit/shipkit-auto-version#72 [2] https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/ [3] shipkit/shipkit-changelog#97 Closes: #442 PR: #466
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Update release notes if tag already exists to better support teams that release on demand.
githubReleasetask performs the release, fails when the tag already exists (error is returned from GH API REST call).Implementation note: it should work for the case when someone pushed a tag via Git push (in this case the release does not exist but the tag exists) or when someone created GH release via UI (release exists, tag exists).
The text was updated successfully, but these errors were encountered: