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".
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.
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.
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
Fixes a bug where commits with messages that do not strictly conform to
conventional commits spec would be ignored. This could easily happen
while parsing footers like "Closes #xx" which would start the footer
section, while continuing with the body afterwards.
This solution has two downsides:
- these warnings are not surfaced to the user.
- If a `BREAKING CHANGE` footer exists after the parsing issue it is ignored
Co-authored-by: jo <ljonas@riseup.net>
When the release pull request was squashed on GitLab, the release
creation fails with error
Error: failed to create pending releases: pull request is missing the merge commit
This fixes the problem by checking both `MergeCommitSHA` and
`SquashCommitSHA` and using whichever is set.
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
Turns out that all we need is the path, and not the project id. The path
is way more user friendly, and we can easily get it from a CI variable
or combine it from the namespace & project name.
GitLab generates commit messages of the pattern "scope: message\n" if no
body is present. This throws up the conventional commits parser we use,
and results in the error message "missing a blank line".
We now `strings.TrimSpace()` the commit message to avoid this problem.
The GitLab project ID was still hardcoded to my playground project on
GitLab.com.
This commit instead reads from the predefined GitLab CI/CD variable for
the projects ID (`CI_PROJECT_ID`).
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.
- PR Description
- Read prefix+suffix from PR description and put into changelog
- Keep those overrides on PR description changes
- Add pending level to new PRs
