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>
The current value caused the following error when running the action in
a different repository:
Error: 'ghcr.io/apricote/releaser-pleaser:v0.4.1' should be either '[path]/Dockerfile' or 'docker://image[:tag]'.
Not sure why this did not come up before, as we are also using the same
format for the CI in this repository, even if we use another tag.
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`).
