Only display prompts if connected to a terminal

[oatovar]

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

I'd like to use changie for automation, but prompts are always displayed without checking for interactivity. This makes it hard to use for automation purposes, and risks a never ending job if it runs in a CI/CD context.

Describe the solution you'd like

I'd like for changie to check for an active terminal before prompting.
If no terminal is connected, it should not prompt, and validate that it has enough data to create the changes. The golang.org/x/term package could be used to verify this.

Describe alternatives you've considered

It would also be helpful to have the ability to define null/empty values for custom data.

Additional context

I'm using changie as part of some dependency update automation. I'd like for every change submitted to include the kind and body. Due to some restrictions that are outside of my control, I'm unable to add the merge request ID until after the change has been merged.

To workaround this, I'm setting the MR custom data to 0, but this is brittle. If I want to add some additional custom data in the future, I have to go back and make sure our automation also adds the zero value when calling changie new. If not, the pipelines will stall waiting for human input.

[miniscruff]

I think it would be an incompatible change to simply accept the values even if interactions are not possible. I can see some users expecting it to fail if new fields are added. I think another cli argument would work better.

You mentioned a separate issue of being able to define defaults for custom properties and I think that would also be nice, even if you were prompted. As in, it would be the default placeholder, but if you disabled prompts that's the value it would use.

[oatovar]

I think it would be an incompatible change to simply accept the values even if interactions are not possible.

Could you expand on this some more? My understanding is that this should still validate the data that was passed in. In my use case, I would expect these two to work.

changie new -k "Maintenance" -b "Update Docker to v28"
changie new -k "Maintenance" -b "Update Docker to v28" -m=MR=1

However, I don't think that this should work because the kind and body are not optional.

# Example of how it should fail
$ changie new -k "Maintenance"
Error: body not set

If someone added some required custom data, something similarly should occur.

# Say that "approver" is now required for example
$ changie new -k "Maintenance" -b "Update Docker to v28"
Error: "approver" field required

I can see some users expecting it to fail if new fields are added.

In my opinion, this would be covered by the optional attribute. If someone expects it to fail then this shouldn't be optional but required, and it should indeed fail when the validation runs.

You mentioned a separate issue of being able to define defaults for custom properties and I think that would also be nice, even if you were prompted. As in, it would be the default placeholder, but if you disabled prompts that's the value it would use.

The default value fits in a bit oddly when you consider the optional value. This is why I mentioned it as a secondary approach. A choice would have to be made on how to handle optional types with default values. One option could be to make them mutually exclusive, so a user must choose to either make it optional or required with a default. I haven't had a good experience with this approach. The urfave/cli project allows this, even in the newly released v3, but it makes for a confusing experience in my opinion. Take the example from the docs. The default value is english for the flag, but since it's required the flag must be set by the user which makes the default value irrelevant. If I had to choose, I would vote against this option. Another could be to allow users to have some sort of empty value as a default. That way optional values could default to this empty value.

[miniscruff]

Ok scratching the default value for now, maybe placeholder would be more accurate to my idea. To your original point, I think we just need to include a new argument, something like '--no-prompt' (tbd) which would fail on any required and not provided field instead of prompting.

[oatovar]

Would it be possible to attach this behavior to the CI env variable or another variable? This is a common pattern used to automatically trigger this behavior. It also reduces the repetitive --no-prompt additions when writing a script

---

I want to directly thank you for your work on this tooling. The departure from commit based changelogs has been so helpful, and this has been instrumental in solving a paint point in our development workflow. 😄

[miniscruff]

Hmm I thought I allow cli args to also use env vars but I could be wrong. We should definitely support both.

Oh thanks, yea I am glad so many people are using changie.

[miniscruff]

Oh, I realize now what you were saying about CI. Hmm, Yea I wonder if we should make CI=true also count as --no-prompts/NO_PROMPTS=true. I wonder if we should also consider TERM=dumb as a don't show prompts either option. Not sure if that one is already handled by the prompts system though.

[oatovar]

I wasn't able to find any env vars to configure changie, but I think this can be easily added, and can open a PR for this later today. I'll also check if TERM=dumb is handled by the prompt system.