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.
* refactor: interface for commit message analyzer
* refactor: interface for versioning strategy
* refactor(releasepr): rebuild pr description
Build PR description from scratch and parsed values instead of copying some of the AST to next description.
- 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
