Support for tab completion

[woodruffw]

First of all, thanks for creating cargo-release! I use it in virtually all of my Rust projects, and it's an absolute pleasure to use.

This PR introduces self-generating tab completion (aka "shell completion" in some shells) to cargo-release. It uses clap's built-in tab completion generation, by way of structop. Every shell completion dialect supported by clap is transparently supported by cargo-release.

By way of example, this command can be used to load shell completions for cargo-release into a bash session:

eval "$(cargo-release completions --shell=bash)"

This is similar but not identical to the CLI provided by tools like rustup, which exposes rustup completions [tool] [shell] to provide completions.

Let me know what you think! I'm happy to tweak the behavior, as desired.

[woodruffw]

The "Lint Commits" action is failing, although I'm not sure whether it's my fault or not 🙂

Linting commits:
* 099d328 main, args: support for tab completion
Against 'committed.toml':
ignore_author_re = 'dependabot'
subject_length = 50
subject_capitalized = true
subject_not_punctuated = true
imperative_subject = true
no_fixup = true
no_wip = true
hard_line_length = 0
line_length = 72
style = 'conventional'
allowed_types = [
    'fix',
    'feat',
    'chore',
    'docs',
    'style',
    'refactor',
    'perf',
    'test',
]
merge_commit = false

If this fails, don't sweat it. We're trying to encourage clear communication and not hinder contributions.
If it is a reasonable issue and you lack time or feel uncomfortable fixing it yourself,
let us know and we can mentor or fix it.
099d3286839be9569c62455a85549effd46b3a80: error Invalid commit format invalid commit format

[epage]

Any particular reason you did case insensitive?

[woodruffw]

Nope, no particular reason. If I had to contrive one, people might do --shell=Bash or similar and reasonably expect that to work. But I don't mind changing it to case sensitive at all, to keep the possibilities simpler.

[epage]

How come you did it at this level? I'm assuming most people will be running cargo-release as cargo release and not cargo-release.

[woodruffw]

I put it at the top-level since that's how rustup and a few other tools in the Rust packaging/toolchain ecosystem do it. My argument for that would be that cargo release is how people should be running it interactively, but cargo-release completions [...] makes more sense in the context of a shell profile (to emphasize that the completions are coming from just cargo-release and that they aren't hooked up to the cargo completions yet).

[epage]

The "Lint Commits" action is failing, although I'm not sure whether it's my fault or not slightly_smiling_face

The complaint is

099d328: error Invalid commit format invalid commit format

ie it isn't following conventional commit but also note it says

If this fails, don't sweat it. We're trying to encourage clear communication and not hinder contributions.
If it is a reasonable issue and you lack time or feel uncomfortable fixing it yourself,
let us know and we can mentor or fix it.

I need to go back and look at getting color enabled (the underlying tool supports it) so it'll be easier to see the problem.

[epage]

How should we document this capability, including giving the example code you had in the R?

We could probably put it in the long help for the command.

[woodruffw]

Hmm, perhaps an FAQ entry? The example I included in the top comment is extremely specific to bash, so including it in the long help might confuse users of other shells (zsh, fish, etc.)

We could also do it in the "reference" docs, although those seem to cover just the release subcommand so perhaps not...

[woodruffw]

ie it isn't following conventional commit but also note it says

Thanks! I misread that error as the tool complaining about the commit's hash, not the commit message body. I'll tweak and amend the PR to bring it into compliance.