feat: detect changed pull request description and retry process #197
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #197 +/- ##
==========================================
- Coverage 25.24% 24.75% -0.50%
==========================================
Files 22 22
Lines 1767 1802 +35
==========================================
Hits 446 446
- Misses 1293 1328 +35
Partials 28 28 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This was referenced Jun 14, 2025
apricote
added a commit
that referenced
this pull request
Jun 14, 2025
apricote
pushed a commit
to hetznercloud/fleeting-plugin-hetzner
that referenced
this pull request
Jun 16, 2025
…etznercloud/fleeting-plugin-hetzner!252) This MR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [apricote/releaser-pleaser](https://gitlab.com/apricote/releaser-pleaser) | repository | minor | `v0.5.1` -> `v0.6.0` | --- ### Release Notes <details> <summary>apricote/releaser-pleaser (apricote/releaser-pleaser)</summary> ### [`v0.6.0`](https://gitlab.com/apricote/releaser-pleaser/blob/HEAD/CHANGELOG.md#v060) [Compare Source](https://gitlab.com/apricote/releaser-pleaser/compare/v0.5.1...v0.6.0) ##### ✨ Highlights ##### Reduced resource usage `releaser-pleaser` now uses less resources: - It now skips pushing changes to the release pull request if they are only a rebase. - The configurations for GitHub Actions and GitLab CI/CD now makes sure that only a single job is running at the same time. On GitHub unnecessary/duplicate jobs are also automatically aborted. - It handles the stop signals from the CI environment and tries to exit quickly. \`\`\`yaml concurrency: group: releaser-pleaser cancel-in-progress: true \`\`\` ##### Avoid losing manual edits to release pull request Before, releaser-pleaser was prone to overwriting user changes to the release pull request if they were made after releaser-pleaser already started running. There is now an additional check right before submitting the changes to see if the description changed, and retry if it did. ##### Proper commit authorship Before, the release commits were created by `releaser-pleaser <>`. This was ugly to look at. We now check for details on the API user used to talk to the forge, and use that users details instead as the commit author. The committer is still `releaser-pleaser`. ##### Features - real user as commit author ([#​187](apricote/releaser-pleaser#187)) - avoid pushing release branch only for rebasing ([#​114](apricote/releaser-pleaser#114)) - colorize log output ([#​195](apricote/releaser-pleaser#195)) - graceful shutdown when CI job is cancelled ([#​196](apricote/releaser-pleaser#196)) - detect changed pull request description and retry process ([#​197](apricote/releaser-pleaser#197)) - run one job concurrently to reduce chance of conflicts ([#​198](apricote/releaser-pleaser#198)) ##### Bug Fixes - crash when running in repo without any tags ([#​190](apricote/releaser-pleaser#190)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MC41Ny4xIiwidXBkYXRlZEluVmVyIjoiNDAuNTcuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 lose 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