Automated changelog tool for preparing releases with lots of customization options

Closes #204

Check the following

• [X] Keep 100% code coverage
• [X] Be properly formatted
• [X] Have no linting errors
• [X] Documentation changes are included
• [X] Include a change file if expected

Additional context

Closes #238

Check the following

• [x] Keep 100% code coverage
• [x] Be properly formatted
• [x] Documentation changes are included
• [x] Include a change file if expected

Additional context I have added the NewLines struct to the Config struct. In WriteTemplate added 2 parameters instead of pregap boolean and changed it in the batch.go

Is your feature request related to a problem? Please describe. I am using prereleases (aka release candidates) and release with a suffix. Ex: v1.5.0, v1.5.1-staging, v1.5.2-staging, v1.5.2

Bumping a prerelease with changie next currently doesn't work when both kinds are present. Ex: In .changes, I have a v1.5.0.md and a v1.5.1-staging.md created. Without the --prerelease flag, changie next ... works fine:

changie next patch
v1.5.1
changie next minor
v1.6.0

But with the --prerelease flag, I have the same result, with the prerelease suffix. I would expect that changie next --prerelease checks the latest version with a suffix rather than the latest release. Ex: how it behaves now:

changie next patch --prerelease staging 
v1.5.1-staging

how I would expect it to behave:

changie next patch --prerelease staging 
v1.5.2-staging

I understand that the existing feature is not wrong. Actually, it behaves as expected when there is NO pre-release following the latest release yet. For example:

v1.5.0
v1.5.1-staging
v1.5.1

And this is ok:

changie next patch --prerelease staging
v1.5.2-staging

Describe the solution you'd like I'd like to implement a new flag to changie next to more accurately define the result, according to expectations.

• by default: current behavior
• --from-latest=prerelease (with --prerelease flag set): evaluates the latest version, including the ones suffixed as prereleases and bumping from there if any is found

Describe alternatives you've considered I've been tinkering with resolving the expected next release, either manually, or inferring it from git tags, but in the end, this is always more complex and fuzzing the clear and logical path set when I've introduced changie to my repos.

Additional context Add any other context or screenshots about the feature request here.

Description With Changie v1.10.0 batch command with "version" and existing .changes/<version>.md file, and some change fragments, contents are lost

Reproduction Steps Steps to reproduce the behavior:

1. Add some change fragments with new command
2. Generate a version with batch command (i.e: batch 4.10.0)
3. Commit the .changes/4.10.0.md file in git repository
4. Add some other change fragments
5. Re-generate the same version with same command (i.e: batch 4.10.0)
6. Contents of .changes/4.10.0.md has only last change fragments added

What happened Contents of a version file is not merged with previous contents and new fragments

Expected behavior Don't lost contents of previous file when exists

Additional context

Initial contents of version file (i.e: .changes/4.10.0.md)

## 4.10.0 - 2022-11-12

### Changed

- `db:build` and `db:release` commands are only available when development mode is active (env var `APP_ENV` sets to `dev`)

Add new fragments into .changes/unreleased folder

• .changes/unreleased/Changed-20221114-073757.yaml

kind: Changed
body: Xdebug reference updated to version 3.2.0RC2
time: 2022-11-14T07:37:57.8894676Z

• .changes/unreleased/Fixed-20221114-073426.yaml

kind: Fixed
body: support to Solr 2.6.0 (see commit https://github.com/php/pecl-search_engine-solr/commit/080b98389a2c05ba68bb613e3a266dbf216340de)
time: 2022-11-14T07:34:26.3090988Z

Final contents of .changes/4.10.0.md after command batch 4.10.0

## 4.10.0 - 2022-11-14

### Changed

- Xdebug reference updated to version 3.2.0RC2

### Fixed

- support to Solr 2.6.0 (see commit https://github.com/php/pecl-search_engine-solr/commit/080b98389a2c05ba68bb613e3a266dbf216340de)

Work around is to keep all change fragments (batch version -k) since we started a new version until it is really merge into CHANGELOG.md

Is your feature request related to a problem? Please describe. We first added changie to our core repo. We list all contributors in the footer of every changelog. Our definition of a contributor is someone not on our team. To ensure we don't list our internal team as contributors we have a hardcoded list of GitHub handles in the .changie.yaml to filter our core team members. Every time a team member would leave or join, we have to go in to modify this list to ensure it stays up to date.

After using changie for a few months we decided to expand to use on multiple other repos within our org. Now, when team members change, we have to go update multiple repos with just a handle add or removal. We no longer have a single source of truth and it is easy for this list to get out of sync.

Describe the solution you'd like We have automated our changelog generation with GitHub Actions. Where I would ideally like to go with this is to be able to query the GitHub Group membership for my team in previous workflow step and grab the members that way. Then pass that list in as a CLI argument (--vars ?) that I can then access in .changes.yaml.

Not sure of the exact syntax but something to this effect:

changie batch --vars '{"core-team": "user1 user2 user3"}

This would allow for a single source of truth as to who our team members are.

Describe alternatives you've considered Continuing to maintain the list in multiple places.

Additional context I think it's important to note the .changes.yaml files have differences between the repos as we require different kinds.

Is your feature request related to a problem? Please describe. I have a lot of complex logic involved with formatting my changelog based on kind and custom key that could be eliminated if I could format when generating the yaml.

Describe the solution you'd like I'm not sure how you would refer to it but something like the following so that I could then refer to .Custom.Issue in multiple other places without having to build the link everywhere. I have an added step of complexity where I can refer to two different repos so the value of repo-name is dynamic. It's determined by the Kind so I would actually need to be able to define the custom format per kind.

custom:
  - key: Issue
    label: GitHub Issue Number
    type: string
    customFormat: ([repo-name/#{{.this.input}}](https://github.com/dbt-labs/dbt-docs/issues/{{.this.input}})

Describe alternatives you've considered Continuing to use the more complex templating I'm using. It works 😃

Additional context Add any other context or screenshots about the feature request here.

• fixes #280

Signed-off-by: Frederic BIDON [email protected]

Closes #NNN

Check the following

• [ ] Keep 100% code coverage
• [ ] Be properly formatted
• [ ] Documentation changes are included
• [ ] Include a change file if expected

Additional context Any additional info that might help get your pull request merged.

Closes #230

Check the following

• [ ] Keep 100% code coverage
• [ ] Be properly formatted
• [ ] Have no linting errors
• [ ] Documentation changes are included
• [ ] Include a change file if expected

Additional context This is based on PR #232 and as such includes its changes.

@miniscruff - Here is my take on how to close 230. I'm open to any feedback you have. The tests will NOT pass because I changed the signature of BatchPipeliner interface to make this work. I'm happy to fix up the tests and adjust the documentations if you think this change is the right way to go about doing this.

IMO this allows the for the most flexibility on the end user's part because the header and footer can just be plain files OR they can be templates AND allows it to be configured as ephmeral or persistent. This also means we could do a follow on which adds a new flag & config body-path / bodyFormat which could allow for the batch body to be completely built up using a template too for maximum flexibility for a power user to fully leverage sprig templates.

Also then going 1 step further we could completely remove the BatchPipeliner.WriteChanges function by converting it's logic to the default bodyFormat by leveraging sprig to provide as an example of how powerful and configurable the template format can be.

Closes #225

Check the following

• [ ] Keep 100% code coverage
• [ ] Be properly formatted
• [ ] Have no linting errors
• [ ] Documentation changes are included
• [ ] Include a change file if expected

Additional context Any additional info that might help get your pull request merged.

Is your feature request related to a problem? Please describe. In cases where I want to incrementally generate a single changelog file from unreleased changes e.g. after merging a Pull Request with its own changes/unreleased/example.yml, I'm not able to do so with changie batch $(changie latest) as this will overwrite the existing file associated with changie latest instead of appending to it.

Describe the solution you'd like In the event I have an existing changelog file in changes/, e.g. changes/v1.1.0.md which is the latest, I would like to be able to append to it with the content in changes/unreleased/ e.g. changes/unreleased/bug-fix-1.yaml such that either:

• changie batch $(changie latest) does not overwrite the existing changes/v.1.1.0md with only the unreleased content
• or a new subcommand is available to support appending e.g. changie add $(changie latest)

Describe alternatives you've considered Only generate a single changelog file from unreleased changes in batches, i.e. just before a release

Additional context I am running changie in Github Actions and have a closed pull_request trigger, such that after a PR is merged, i would like to append its respective changelog to the existing versioned release markdown file.

Problem and Use Case

At the moment, the body of a changelog entry cannot contain any newlines. If you use "Upgrade Notice" or "Deprecated" kinds in your changelog, it is ofter required to write more than one sentence. As Markdown (and YAML) allows line breaks in list items if they are indented correctly, Changie should also support such entries.

Suggestion

The body prompt for a new entry should be modified so a newline character is not interpreted as the end of the entry. A specific character sequence (EOF or a dot) can be used instead of the newline character.

The resulting YAML file might look as follows:

kind: Removal
body: |
  This is the first,
  and this the second line!

Bumps golang.org/x/text from 0.5.0 to 0.6.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps peaceiris/actions-gh-pages from 3.9.0 to 3.9.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Windows now has a built in package manager called winget. It would be really nice if I could install changie with winget, rather than having to install scoop.

It looks like all you need to do is add a manifest to https://github.com/microsoft/winget-pkgs

Is your feature request related to a problem? Please describe.

The input for a change might contain more complex changes. I'd like to write multiple lines.

Describe the solution you'd like

The body should be a multi-line input and this should be saved via

---
body: |
  my content
  
  - Item 1
  - item 2

Describe alternatives you've considered

I use gum for this.

Additional context

Currently the input once exceeding the width of the terminal incorrectly reflects repeated lines. See attached gif.

• answers are repeated on latest version so using an older one
• when an error occurs the answer is not cleared

Closes #119 Closes #373

Check the following

• [ ] Keep 100% code coverage
• [ ] Be properly formatted
• [ ] Documentation changes are included
• [ ] Include a change file if expected

Additional context Any additional info that might help get your pull request merged.

Description

When editing the body of a new entry, if I go back in the line and press Suppr to delete a character, Changie quits.

Reproduction Steps Steps to reproduce the behavior:

1. Run 'changie new'
2. Select a kind
3. Start typing
4. Press ← to go back a few characters
5. Press Suppr

What happened Changie quits like this:

Error: ^D
Usage:
  changie new [flags]

Flags:
  -b, --body string        Set the change body without a prompt
  -c, --component string   Set the change component without a prompt
  -m, --custom strings     Set custom values without a prompt
  -d, --dry-run            Print new fragment instead of writing to disk
  -h, --help               help for new
  -k, --kind string        Set the change kind without a prompt

Expected behavior The character under the cursor is deleted.