Adding new command to encrypt the variable like in pipeline.

[joshirohit100]

Issue - https://github.com/acquia/cli/issues/1661

New Command -

./bin/acli pipeline:encrypt-var texttoencrypt

./bin/acli pipeline:encrypt-var --help
Description:
  Get the encrypted text to be used for pipeline

Usage:
  pipeline:encrypt-var <encrypting_string> <applicationUuid>
  pipeline:encrypt-var SOMESTRINGTOENCRYPT APPUUIDHERE

Arguments:
  encrypting_string     Text that to be encrypted
  applicationUuid       The Cloud Platform application UUID or alias (i.e. an application name optionally prefixed with the realm)

something same which is provided by pipeline client encrypt command

[joshirohit100]

If this is fine (approved), will add the tests

[danepowell]

Why not just use the Pipeline CLI for this? I'm not happy about the idea of duplicating functionality between Acquia CLI and Pipeline CLI piecemeal. If we're going to merge Pipeline CLI into Acquia CLI, it needs to be part of a coordinated effort.

If this is important to you, let me know as we'll need to create spike ticket and figure out how to prioritize it.

[danepowell]

Our original vision was to eventually migrate all of the code in Pipeline CLI into Acquia CLI. I no longer think that's feasible since there's just so much of it.

This command is minimal by comparison because it's missing a lot of features of Pipeline CLI such as input validation, the ability to set custom endpoints, etc

Basically, this sets a precedent for the migration of a limited set of features from Pipeline CLI rather than the whole kit and kaboodle.

I'm okay with that but I want to see if @anavarre agrees. My worry is that the sort-of-but-not-quite duplication of functionality between Pipeline CLI and Acquia CLI will create confusion for customers. On the other hand, I think this migration can only ever happen in this piecemeal fashion, and there is value in deprecating Pipeline CLI.

[anavarre]

Yes, I'm afraid we don't want to set this precedent. Whatever relates to Pipelines CLI needs to be developed there until we hypothetically decide to merge both CLI together. The separation of concern is important IMHO.

[danepowell]

Sorry @joshirohit100 , I'm afraid we can't accept this.