It appears that `Sprig` flips the inputs of the `contains`, `hasPrefix`, `replace`
and `hasSuffix` `strings` methods. This appears to be the cause of the regression.
See: https://github.com/Masterminds/sprig/blob/master/functions.go#L149-L152
This results in a regression against the previous implementations of the template
functions.
Signed-off-by: Derek Smith <derek@clokwork.net>
* feat: add docker image on release and master
* resolves return on the PR
* Add Installation docker doc
* Update .github/workflows/publish.yml
Co-authored-by: Derek Smith <derek@clokwork.net>
* Resovle PR conversations
* No v in RawVersion
Co-authored-by: Derek Smith <derek@clokwork.net>
* cherry-pick from delmendo
* add tests, docs, and lift hermetic restriction
* remove duplicate funcs that are now provided by sprig
* switch func load order to allow built-ins precedence
* Update chglog.go
Co-authored-by: Dirk Elmendorf <dirk@r26d.com>
With the migration to GitHub Action, there's no need to continue to use
AppVoyer to only test on Windows, as it's covered by corresponding new
jobs.
Signed-off-by: Khosrow Moossavi <khos2ow@gmail.com>
When attempting to render a commit body below the summary line of the
commit there are two problems:
1) The text needs to be indented two spaces to appear as part of the
list.
2) Notes (e.g. BREAKING CHANGE) are included in the body and end up
being repeating in a Notes section (if this is part of your template).
To address #1 add an `indent` func to the template parsing.
To address #2 add a `TrimmedBody` to the `Commit` fields.
The `TrimmedBody` will include everything in `Body` but not any
`Ref`s, `Note`s, `Mention`s, `CoAuthors`, or `Signers`.
Both the CoAuthors and Signers are now first class in the Commit
struct.
With both of these a template block like:
```
{{ if .TrimmedBody -}}
{{ indent .TrimmedBody 2 }}
{{ end -}}
```
Will render the trimmed down body section as intended.
See TestGeneratorWithTimmedBody for example of desired output.
Relates to #123.
While this does not introduce "per-branch" tag parsing it does allow an
alternative tag sorting method which maybe a better solution.
With this commit the user can decide to sort the tags by semver instead
of dates.
This is useful where repositories are utilizing a stable branch model
and back-ports are interleaved with new releases.
For example, if your mainline is on v3.0.0 with it's last release
1/1/2021 and a back-port release of v2.0.1 is released on 1/2/2021,
sorting by semver will correctly order the change log producing
v2.0.1 -> v2.0.1 -> v3.0.0
This functionality is completely opt-in and defaults to the original
"date" sorting
Signed-off-by: ldelossa <louis.delos@gmail.com>
