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.
