In a timing issue, the release pull request may be created but the
releaser-pleaser labels not added. On the next run releaser-pleaser
then creates a second release pull request. We try to reduce the chance
of this happening by checking the context cancellation at the top, and
if its not cancelled we run both API requests without passing along any
cancellations from the parent context.
Closes#215
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.
This change allows detecting that the releaser-pleaser PR is well merged.
As of today, it fails with "ERR failed to create pending releases: pull request is missing the merge commit".
Each run of releaser-pleaser acts on the same global state in the
forge. Therefore, parallel runs are unnecessary.
This commit also communicates to the GitHub and GitLab CI pipelines that
the releaser-pleaser jobs can be cancelled as early as possible.
- On GitHub Actions this can be guaranteed through the workflow
settings. These settings are copied into each repository that uses
releaser-pleaser, so users need to update this manually. I will add a
note to the release notes for this.
- On GitLab CI/CD this requires the user to configure a project level setting to
"auto-cancel redundant pipelines". We will not recommend user to set
this, as it is quite invasive and can break their regular CI pipelines.
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
By listening on SIGINT and SIGTERM signals we can stop executing as soon
as reasonably possible. This helps to avoid uncessary work and stop the
job earlier.
Right now we have no manual checks for cancelled contexts, and rely on
the http client to check for it while making requests.
The whole check to avoid pushes when they were only rebases was broken
and compared the wrong things. Unfortunately this worked for nearly all
unit tests, except for one were I used the wrong assertion.
This fixed the check by comparing the right things and inverting the
assertion in the unit test to make sure things do not break again in the
future.
Bug was introduced in #114.
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.
