feat: new cli support

[chen-keinan]

Description

New cli support

Close

• 96148
• 96650
• 96660

This enhancement supports the following commands:

• Create Release Step
• Deploy Release Step
• Pack Package Step
• Push Package Step
• Build Information Step

Note: Promote Release is not included, as it is not supported by the new CLI. If a user invokes Promote Release, the system will fall back to the old CLI.

Support for the new CLI is controlled via the environment variable OCTOPUS_NEW_CLI. By default, the Legacy CLI is used.

[zentron]

Will continue and read through it, but run into a problem.

I've created a CreateRelease step via the old cli, gone to use it with the new cli, and ran into an issue due to a default parameter no longer being default

 Running command:   octopus release create --project SimpleArgo --output-format json --no-prompt
  Creating Octopus Deploy release
  Starting process...
  space must be specified when not running interactively; please set the OCTOPUS_SPACE environment variable or specify --space on the command line

It appears that SpaceId, which was previously optional (I think it would default to looking for Default) is now required in the new cli.

Consider how we want to deal with this change. The simplest might be to hard-code the default to Default outside the cli invocation if its not set in the form, but perhaps first confirm that this kind if behaviour is what happens with the old cli

Are there any other fields that are no longer optional?

[zentron]

The logs also look much quieter. Is there a more verbose flag we can perhaps provide?

After

[zentron]

Not particularly a problem, but out of interest why use a fork rather than working off the main repo?

[chen-keinan]

Not particularly a problem, but out of interest why use a fork rather than working off the main repo?

I didn't had permission to push to the repo and since it is public repo I thought this is how we work with it :)

[chen-keinan]

It appears that SpaceId, which was previously optional (I think it would default to looking for Default) is now required in the new cli.

Thanks for the reminder also saw it now as I was preparing a Demo for EMEA, I will add it Default value

Consider how we want to deal with this change. The simplest might be to hard-code the default to Default outside the cli invocation if its not set in the form, but perhaps first confirm that this kind if behaviour is what happens with the old cli

Are there any other fields that are no longer optional?

there are no additional fields that are no longer optional

[chen-keinan]

The logs also look much quieter. Is there a more verbose flag we can perhaps provide?

unfortunately no, there is no verbose flag in the new cli

[zentron]

Thanks @chen-keinan, appreciate the slow back and forth with this one.

One, hopefully last question, is with regards to the Additional Fields property on the steps. When these steps are using the old cli, then any value customers have set there will presumably be working. When it toggles to the new cli tool however, these will be unlikely to work.

There is a brief mention of this "problem" in this ticket.
The thinking will be that we should default the toggle to on this additional field is not supplied.

Given this current work really only takes affect if the feature toggle is on, im assuming that the plan is merge this work in, safely behind the feature toggle, then look at setting it up to be the default, with appropriate warnings etc?

[chen-keinan]

Thanks @chen-keinan, appreciate the slow back and forth with this one.
Given this current work really only takes affect if the feature toggle is on, im assuming that the plan is merge this work > in, safely behind the feature toggle, then look at setting it up to be the default, with appropriate warnings etc?

@zentron thanks for the feedback. I have a few questions to make sure I understand the requirements correctly before implementing it:

In the ticket you mentioned three main conditions that should cause the plugin to fall back to the Legacy CLI:

a. If the environment variable OCTOPUS_LEGACYTCPLUGIN=true — does that mean the plugin will run the new CLI by default unless this variable is set?

b. If the Additional fields contain options that are not supported by the new CLI.

c. If the server version is lower than 3+.

When either condition (a or b) occurs, a warning log should be written at the beginning of the task and in the UI logs.
I assume “task and UI logs” refer to the build log in the UI and the agent logs — is that correct?

In any case, we should also log a warning that usage of v1 and v2 servers will not be supported in future plugin versions.
Should this warning appear in the agent log or the build log?

[zentron]

In any case, we should also log a warning that usage of v1 and v2 servers will not be supported in future plugin versions.
Should this warning appear in the agent log or the build log?

Yep thats a good idea. I would probably say in the build log since thats probably more prominent. What do you think?

Given the las bits to put in place before we can enable by default, im fine for you to merge what you have before tackling the next part to make it use the new cli by default.

Thanks for looking into this one.

[chen-keinan]

In any case, we should also log a warning that usage of v1 and v2 servers will not be supported in future plugin versions.
Yep thats a good idea. I would probably say in the build log since thats probably more prominent. What do you think?

yes , I think we are on the same page on this one :)

[chen-keinan]

Duplicate to #183