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
With `pull_request`, we run in the context of the pull request branch.
- This means we run with the code from the PR branch, possibly breaking
the current release PR for this repo with in-progress, unreviewed changes.
- This means that the secret is not available on Pull Requests from
forks.
Switching to `pull_request_target` means we always run in the scope of
the original repository. The secret is available and the code is checked
out from our main branch.
`pull_request_target` has security considerations, but they do not apply
here as we do not check out or run code from the (external, malicious) PR.
The previous job always used the last release version of
releaser-pleaser. This caused two issues:
- if new flags were added to `action.yml` since the last release, the
program errored because the flags are unknown.
- right after merging a release pr, the image reference was already
updated, but no new container image was built yet.
This fixes both issues, by using a locally built version of
releaser-pleaser, which is always up-to-date and available.
