Align configuration support across plugins

[moritzraho]

This issue updates and generalizes the discussion in https://github.com/adobe/aio-cli-plugin-console/issues/149 to the whole CLI.

This is the result of an internal team discussion, points mentioned here were brought by @Himavanth @meryllblanchet @purplecabbage @rajarju @shazron @sandeep-paliwal

Problem statement

We observed a confusion from our users when working with the global (~/.config/aio) and local (.env and .aio) configuration. Plugins do not all support global and local configurations in the same way.

More precisely what we call local configuration is actually the app configuration, and what we call global configuration is the cli configuration.

Identified issues - Propositions

Configuration display

aio where shows only the cli console configuration, for example

> aio where
You are currently in:
1. Org: company
2. Project: coolproject
3. Workspace: Production

This brings confusion when running the command from an application folder. Instead a better solution would be to print out the cli and the app config (if any).

> aio where

Your application is in:
1. Org: company2
2. Project: coolproject2
3. Workspace: Stage

Your CLI is in:
1. Org: company
2. Project: coolproject
3. Workspace: Production

Or

> aio where

Your are not in an application folder

Your CLI is in:
1. Org: company
2. Project: coolproject
3. Workspace: Production

Also note that aio where is not the only command that prints the Console configuration. The same happens in aio login, aio-cli-plugin-events and other places that we need to review.

As mentioned in https://github.com/adobe/aio-cli-plugin-console/issues/149 there might be an opportunity to unify the config output logic in a single library.

aio app use rewrites cli config

Updates to the app configuration via aio app use in a local application folder, will overwrite the global cli config, this should not happen.

aio console workspace select should import credentials for aio-cli-plugin-runtime

The Runtime plugin supports both the app and cli configuration, however selecting a new workspace via aio console select workspace does not import the Runtime credentials, meaning the Runtime credentials must be set manually in ~/.config/aio. There is an opportunity for improvement here.

Support for multiple environments (1st party)

Adobe internally uses multiple environments to test its services. Our app and cli configuration system should be capable of holding multiple simultaneous configs for each environment, for example a stage and prod config could live together.

Investigate and unify experience

On top of the issues mentioned above, a review on how each plugin interacts with the app and the cli configuration is necessary to identify what could be done to unify the configuration experience.

[theManikJindal]

Radical thought: Is there even a need for global config? What happens if we remove the global config and just keep only the local one everywhere?

[meryllblanchet]

@theManikJindal there are CLI users (developers or CI/CD pipelines) who do not build Firefly apps, but interact with the developer console, cloudmanager, AEM or other product APIs via dedicated plugins.

[moritzraho]

Yes, the global config allows you to run some commands from anywhere in your filesystem. If we only go with local configuration users would get .aio files all over their filesystem and a command might work in one folder but not the other. Global CLI configuration is common practice.

[purplecabbage]

more for @theManikJindal 's question, and the responses. imo we should not write .aio files everywhere, but we always read them ... this allows us to support multilevel config

For the rest, I will need to write something up ...

[PulkitXChadha]

Second that thought, .aio files should not be seen by the end user. They are also not list in .gitignore file generated from aio app init.

I like the idea of showing two sets of configs when you are in an application folder.

Could we have an easy way to sync application config with the global config instead of forcing an overwrite every-time we execute a aio app use?

[purplecabbage]

.aio needs to be ratified into an AIO_AppConfig file and should be checked in usually. This should be a well known and documented definition of the project itself. This swapping out 1 project for another, reusing the source code is exceptional use and not something we should optimize for (at the moment). Most users will never do more than switch workspaces within a project.

To me, this is all akin to storing state and should be kept local, imagine if when you ran git checkout -b new-branch every repo on your machine was suddenly on new-branch

So perhaps I was not clear when I said 'we should not write .aio files everywhere' I meant we should not write them all over the place when commands are run outside of project directories.

[ackoch]

a few random thoughts on

Your application is in:

1. Org: company2
2. Project: coolproject2
3. Workspace: Stage

Your CLI is in:

1. Org: company
2. Project: coolproject
3. Workspace: Production

I agree that we should consistently support both local application and global configurations. But.. we should be more transparent about the implications. E.g. when I see, I am "connected" with two workspaces, what does that mean for commands I call.

Actually I love git for giving me hints and directions directly on the commands.

In that spirit I would word it like:

Your application is in:

1. Org: company2
2. Project: coolproject2
3. Workspace: Stage All commands issued in this folder will be executed against this workspace.

(This overrides the global setting in ~/.aio Org: company, 2. Project: coolproject, 3. Workspace: Production) Use the --global in any aio command to override the application setting by the global per command Use aio app use --global to copy the global configuration into the current application

Vice versa, when we are not in an application folder.. we should emphasise the global config more (and put it first). I'd phrase it like

Your are currently connected to (by the global configuration in ~/.aio):

1. Org: company2
2. Project: coolproject2
3. Workspace: Stage All commands issued in this folder will be executed against this workspace.

(You are not in an application folder)

Something like that

[ackoch]

Usually I move a bit around in an application folder with $ cd ... I find it a bit annoying, that aio rt only work when I am in the application's root folder. When we apply the scheme above that can easily lead to mistakes.. like issuing commands towards the globally selected workspace while I am in a subfolder of an application.. We should instead traverse from the current directory towards the docroot looking for the application root and a .aio file

[ackoch]

I worked with Googles cloud lately...

Here you can have multiple "global named configs" that you can select from (so you don't always have to "select" your way from org to workspace).

Something like

$ aio console where

Your are currently connected by configuration (defined in ~/.aio):

Org: company2 Project: coolproject2 Workspace: Stage All commands issued in this folder will be executed against this workspace. (You are not in an application folder)

$ aio console config create myconfig

Your are currently connected by configuration < myconfig > (defined in ~/.aio):

Org: - Project: - Workspace: - (You are not in an application folder)

$ aio console config list

default myconfig

$ aio console config use default

Your are currently connected by configuration (defined in ~/.aio):

...

You get the point

[meryllblanchet]

This is all great feedback @ackoch ! Let me ping @sarahxxu and @theManikJindal to let them read through as well.