fix(cli): Split diff and non-diff output

[craigfurman]

On commands that produce diffs: diff, apply, and prune.

It is desirable for some use cases to parse diff output from kubectl diff (e.g. secret redaction until
kubernetes/kubernetes#87840 is resolved). This
is a lot easier when diff and non-diff output are not combined on the
same channel, stdout.

This commit moves diagnostic, non-diff output for the 3 relevant
subcommands to stderr.

See https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/tanka-deployments/-/merge_requests/123 for an example of a diff-parsing workflow that would be made easier by this split 🙂.

[craigfurman]

Thanks @sh0rez!

[craigfurman]

Cheers @Duologic and @sh0rez! 🚀

I noticed that the commit message and MR title were changed to a semantic-release style. Is there somewhere I can read about how to name commits, including subsystems like CLI? That way there'll be less maintainer work for my future contributions 😉

[sh0rez]

Hey @craigfurman!

We did not yet setup a CONTRIBUTING.md or similar, so this is all loosely agreed on.
Here is what I tend to do:

Style: kind(scope): msg
Kind:

• feat: add a feature, improve sth existing
• fix: make something incorrect correct
• chore: housekeeping tasks (releasing, docker, ci, etc)
• test: add tests
• style: fix typos, run gofmt, etc
• doc: add documentation

scope:

• api: Everything that is pkg/tanka
• k8s: pkg/kubernetes
• cli: cmd/tk or other cli-only changes
• jsonnet: pkg/jsonnet
• tool/: Changes to tk tool <name> commands
• release: Release related work (usually changelog edits)
• helm: Helm support (excludes tool/charts which is mentioned above)

Treat it as a rule of thumb, it is not definitive. E.g. one could argue this PR is more of a feat than a fix, and the scope could possibly also k8s instead of cli. So really, do what seems to make sense ;)