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
This adds a GitLab CI/CD component that can be `included` in users
GitLab CI configuration to integrate releaser-pleaser.
Unlike the GitHub Action, this can not easily run whenever a merge
request description is changed, only when changes are pushed to main.
Images used in GitLab CI need to have a shell included, otherwise the
job could not be started.
This replaces the default `cgr.dev/chainguard/static` base image with
`cgr.dev/chainguard/busybox`. Busybox is the smallest image that
includes a functional shell.
Needed for #55.
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.
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
