This change reverses the responsibility for which files the updaters are
run on. Now each updater can specify the list of files and wether the
files should be created when they do not exist yet. This simplifies the
handling of each update in releaserpleaser.go, as we can just iterate
over all updaters and call it for each file of that updater.
Also update the flags to allow users to easily define which updaters
should run.
If the release PR description was changed by a human after
releaser-pleaser fetched the PR for the first time, releaser-pleaser
would revert the users changes accidentally.
This commit introduces an additional check right before updating the
pull request description, to make sure we do not accidentally loose user
changes. There is still the potential for a conflict in between us
checking the description is the same, and updating the description. The
time window for this should be reduced from multiple seconds-minutes to
a few hundred milliseconds at most.
In case a conflict is detected, we retry the whole process up to 2
times, to make sure that the users changes are reflected as soon as
possible. This is especially important on GitLab CI/CD because a changed
pull (merge) request description does not cause another job to run.
With this change, the branch is still pushed, as the user is not
expected to make any changes to it.
Fixes#151
Recent changes in v0.5.1 introduced a bug that caused releaser-pleaser
to crash when running in a repository that contained no tags at all.
This fixes the issue by checking if there is a tag before using it in
the logger.
Bug was introduced in #174.
Right now releaser-pleaser pushes the branch even if it is only for a "rebase",
this wastes CI resources. Instead, it should only push when there are changes
to the files it owns.
- **Old**: Push when there is a diff origin/release-pr..release-pr
- **New**: Push when the these two diffs are not the same:
origin/main..release-pr
$(git merge-base origin/main origin/release-pr)..release-pr
Closes#92
Previously all commits were authored and committed by
releaser-pleaser <>
This looked weird when looking at the commit. We now check with the
Forge API for details on the currently authenticated user, and use that
name and email as the commit author. The commit committer stays the same
for now.
In GitHub, the default `$GITHUB_TOKEN` does not allow access to the
required endpoint, so for github the user `github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>` is hardcoded
when the request fails.
If two pre-releases were cut in a row, the second pre-release version
would only consider the semantic changes since the previous pre-release,
but base its new version of the latest tag.
Example:
- stable tag: `1.2.0`
- latest tag: `1.3.0-rc.1`
- 1 commit since with `fix:` tag
The resulting releaser-pleaser tag would be: `1.2.1-rc.2`. It should be
`1.3.0-rc.2` instead.
This is now fixed by considering different commit ranges for versioning
and changelog.
For a stable version we want the list of changes since the stable tag.
For a prerelease version we want the list of changes since the latest
tag. To avoid repeating the same features over and over in a series of
multiple pre-releases.
This behaviour already existed and worked.
For a stable version, we want to consider all changes since the stable
tag.
For a prerelease version, we also want to consider all changes since the
stable tag. This was broken and only used the changes since the latest
tag.
During a previous refactoring (#15) the Changelog generation logic stopped creating the file if it did not exist. This makes sure that the file actually gets created. This is primarily required while onboarding new repositories.
Closes#85
The forge ui usually shows the release name right above the description,
so this removes an unecessary duplicate bit of information.
In addition this also cleans up the changelog interface a bit and moves
functionality where it belongs. Prepares a bit for custom changelogs in
the future.
Closes#32
Makes navigating to the PR way easier when looking at the logs.
This requires a new `Forge.PullRequestURL()` method that needs to be
implemented for all forges.
Right now we always show all new releasable commits since the last
_stable_ release.
If a project publishes multiple pre-releases in a row, they all repeat
the same lines with a few new additions.
On the other hand, when we cut a stable release, we do want to show all
changes since the last stable release, as we can not expect users to
read the changelog of pre-releases.
As a compromise, the code now looks at the type of release that is being
created, and decides based on that if we will look at STABLE..HEAD
(stable release) or LATEST..HEAD (pre-release).
Close#33
