Hide multi-channel license support from CLI

[Justiceleeg]

Story:
https://app.shortcut.com/replicated/story/133383/hide-multi-channel-licenses-in-cli

Multi-channel licenses are gated by a feature flag that's not enabled. Remove CLI exposure to prevent user confusion and API errors.

• Change --channel flag from array to single value
• Remove --default-channel flag
• Simplify channel handling to single-channel only (this will take the last channel passed when multiple channels see below)

NEW BEHAVIOR (multiple channels):

OLD BEHAVIOR (multiple channels):

[marcw-replicated]

These changes look fine to me, but I haven't worked on the CLI yet, so I'll defer to @laverya. My only concern is this appears to be a breaking change since it changes the behavior of an existing command and I don't know if that affects how we release/document this change. @justicelee, can you add to the PR description an example of what happens if you try to execute the old command format?

[Justiceleeg]

@marcw-replicated , yes this does change the api in that it no longer passes along the multiple channel args. but I believe the multi channel feature flag is off/ has always been off in the API so the API always returns that message we see: multi-channel licenses are not enabled. (This change makes it so that the API never returns that error message - the API code doesn't need to be updated)

It also changes the api because it removes the concept of default-channel (this only makes sense in the multi-channel case. In the case of single channel, that one channel is automatically marked default.

Also that screenshot is what happens when you try to execute the old command format (for multiple channels) here is a screenshot for just a single channel (the new behavior):

NEW BEHAVIOR (single channel):

was this what you were asking for?

Edit: I also added the screenshot for current api behavior to the PR descrip.

[marcw-replicated]

Ah, I see now, thanks. So we don't error but just silently accept the last specified channel and ignore the others? Are we good with that? Also, what if the old --default-channel argument is included?

[marcw-replicated]

Just commenting here, because there's no good place for it. I noticed in the output of your screenshots the column header still said "CHANNELS" (plural). That needs to be updated here. There might be other places too, but I'm not familiar with this repo, but it looks like maybe this customer type too?

[Justiceleeg]

i saw that CHANNELS too! But I looked up the git history for that line of code and it has always been plural (since 2019/ before multi-channel). I'd be down to change it to singular but since its always been plural i just left it.

Also that customer type is the API contract which still technically is an array.

Thanks for reviewing all this so well!

[marcw-replicated]

Fair point! 😉 I don't see any reason not to change it to singular though, especially since we're removing this functionality now.

[Justiceleeg]

also: this is what happens when --default-channel flag is passed:

what happens when --channel is not passed at all

[marcw-replicated]

We should probably look into the handling of multiple --channel arguments. I don't love that we don't error in that case, unless only accepting the last one is how all arguments behave (like specifying --name twice).

[Justiceleeg]

@marcw-replicated I'm about to push a commit that does the CHANNELS -> CHANNEL change.

We should probably look into the handling of multiple --channel arguments. I don't love that we don't error in that case, unless only accepting the last one is how all arguments behave (like specifying --name twice).

I could go either way with this. I thought the same at first but I'm told (by AI) that this is a common pattern in the Go library we use, Cobra - the last flag is taken? Also we don't have any instances of that type of validation of inputs in this repo yet. But I can make this change.

[marcw-replicated]

@marcw-replicated I'm about to push a commit that does the CHANNELS -> CHANNEL change.

We should probably look into the handling of multiple --channel arguments. I don't love that we don't error in that case, unless only accepting the last one is how all arguments behave (like specifying --name twice).

I could go either way with this. I thought the same at first but I'm told (by AI) that this is a common pattern in the Go library we use, Cobra - the last flag is taken? Also we don't have any instances of that type of validation of inputs in this repo yet. But I can make this change.

OK, then I'm good leaving it as is. Thanks for looking into it.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Inconsistent field naming between create and update opts

Low Severity

The createCustomerOpts struct uses ChannelName while updateCustomerOpts uses Channel for the same concept. The previous code was consistently plural (ChannelNames and Channels). Using inconsistent naming for equivalent fields across related structs reduces code readability and can cause confusion when working with both commands.

Additional Locations (1)

• cli/cmd/customer_update.go#L16-L17