[FEATURE] more options for cog bump, for example not to generate changelog

[gotson]

Is your feature request related to a problem? Please describe.
I am trying cog on an existing repo using semantic-release. When trying to use cog bump --auto, i get an error:

Error: cannot find default separator '- - -' in CHANGELOG.md

Describe the solution you'd like
In general, i think cog should be less strict with repos having a mixed history of conventional commits, tags, or different CHANGELOG format. This echoes to #212 too.

More widely, cog bump is doing a lot at the moment. I understand some people would like all the bells and whistles, but i also like the unix philosophy that a binary should do one thing.

One reason i am trying to move away from semantic-release is exactly because of that. You can't just get the version from the bump, it will always run hooks, close issues etc. And cog seems to follow the same path.

For instance, one thing you cannot do with semantic-release would be to split the steps, for example if you want to (in CI):

• get the next version
• replace the version in some files
• run 3 different Github Action jobs on 3 different OS to build os specific packages
• then finish the release

cog already has a changelog command. I find it nice that you can do everything with cog bump, which saves the hassle of writing shell scripts to tie everything together, but it should also allow for much simpler behaviours:

• allow for not checking that some files are not added or committed to git
• allow for not generating a changelog
• allow for only computing the next version and output to stdout
• allow for not running hooks
• allow for not generating a commit

For instance if i was to use cog to generate the next version for a SNAPSHOT release in a Maven build, i don't want the commit to be added to git. I also don't want the changelog.

Describe alternatives you've considered
convco follows the unix philosophy and works better in repos with a mixed history of commits and tags, and also an existing changelog

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

[oknozor]

There are a lot of good ideas here ! I tend to strictly follow the conventional commit and semver spec so I am probably missing
some common use case where a less strict approach is preferred.
I was also thinking about adding a ignore-non-conventional-commit field to the configuration to completely ignore non conventional commit during the bump process.

allow for not checking that some files are not added or committed to git

Something like --ignore-unstaged-changes ?

allow for not generating a changelog

--no-changelog

allow for only computing the next version and output to stdout

This probably belongs to a dedicated sub-command, maybe cog next ?

allow for not running hooks

--no-hooks

allow for not generating a commit

--no-commit

To sum up the following flags needs to be implemented and the corresponding configuration fields :

• cog bump --ignore-unstaged-changes
• cog bump --no-commit
• cog bump --no-changelog
• cog bump --no-hook
• cog bump --ignore-unstaged-changes
• cog bump --ignore-unconventional
• cog next

[xmlking]

I generated CHANGELOG.md the first time with cog changelog > CHANGELOG.md and committed.

my cog.toml

tag_prefix = "v"
ignore_merge_commits = true
branch_whitelist = ["master", "main"]

pre_bump_hooks = [
    "echo {{version}}",
]
post_bump_hooks = [
    "git push",
    "git push --tags",
]

[commit_types]

[changelog]
path = "CHANGELOG.md"
template = "remote"
remote = "github.com"
repository = "proto"
owner = "threat-zero"
authors = [{ username = "xmlking", signature = "Sumanth Chinthagunta" }]

[bump_profiles]

when i dry cog bump --auto getting this error:

[oknozor]

@xmlking You just need to prepend - - - to the top of your changelog so cog can prepend the next changelog entry.

[Tenshock]

Another great option with cog bump would be to allow major increment with --auto option with another option like --allow-major I think

[ParaZera]

I was about to submit a new feature request (see below) which very closely relates to some of the features requested here.

What do you think of having 3 "unix-style" commands to allow a high configurability. Something like:

• cog next for calculating and outputting the next version with options like:
  • output the version with or without prefix
  • output a JSON with the major, minor and patch version as different elements
  • output the version based on a template
• cog changelog as it is now
• cog release to create a release commit and tag with options like:
  • include edited / staged files
  • add only a specific set of changed files specified in cog.toml
  • don't error when the git repository is dirty on a release
  • edit the default commit message

cog bump would then become a sort of meta-command with sane defaults and only a subset of the aforementioned config-options. This is to give most users what they need without having to deal with every possible config option. Or, alternatively, just run the three commands in succession according to the settings in cog.toml.

---

Here my already finished feature request to give a concrete use case:

Is your feature request related to a problem? Please describe.
I am using gitlab pipelines with different stages to build, test and release several associated programs (using different docker images / matrix-jobs) under the same version. To do this I first update the VERSION file in the repository using a script with cog bump -ad and passing this as a build artifact to the subsequent jobs.

The last (release) job gathers all artifacts from the previous jobs, commits the VERSION file (among others) and then does an actual cog bump -a which results in 2 'release' commits.

Describe the solution you'd like

• Add an option to write / update the newly calculated version into a file in a parseable format. E.g. simply MAJOR.MINOR.PATCH or as a JSON. The created / updated file within the repository should not throw an error (as it currently does with cog bump -ad > VERSION
• Read the next version from a file in the above mentioned format and include the file in the release commit

Describe alternatives you've considered
The pre- and post bump hooks are not flexible enough, if you require different docker images or create the same program with a different configuration (think: the same firmware for different hardware).

Calculating the version with cocogitto in every pipeline job which requires the version. But this has drawbacks to the proposed change:

• Installing cocogitto on docker images which do not include rust / cargo or are based on archlinux often takes longer than the actual job itself
• When adding the updated version file, a second release commit is required since cocogitto does not include edited / staged files in the release commit. These commits can no be squashed either due to the automatically created tag. (This might be another good feature :) )

[bdarcus]

I was also thinking about adding a ignore-non-conventional-commit field to the configuration to completely ignore non conventional commit during the bump process.

This sounds like a good idea to me.