Closed kwin closed 1 week ago
We will revisite IMS usage in the plugin pretty soon and take this into account in the same go, thank you.
tagged: SKYOPS-76944
@kwin Hi Konrad, can you build and test #96 if this fixes your current situation even tho the ims still stores tokens globally? BTW, can you start slack? :-)
BTW, can you start slack? :-)
You need to invite me, I am currently not part of your Slack workspace ;-)
fixed with v1.3.6
As documentation is not yet published, you can test with below instructions:
npm install -g @adobe/aio-cli
and the tokens are stored locally.
How does storing context locally allow to parameterize the IMS Context name? How do I pass the info which context to use for a specific RDE command?
We now support the default aio way of context handling, which means you can set what context to use using
aio auth ctx -s mycontext
which activates your context. And then you run any rde command.
Your context does not need to be stored locally, this also works when stored globally. We now also just support local contexts on top. We will not introduce a parameter on the rde commands.
Thanks for the clarification @RemoLiechti but that means the current IMS context affects all AIO CLI plugins in the same way, i.e. it is not possible to use different contexts for different plugins. Also switching the current context is basically affecting all AIO CLI executions, so there may be race conditions for automated use cases (although I understood, the current context only ever affects the current directory). Would probably be good to explain how the current context is evaluated a littlebit more in detail in the docs.
This is absolutely true. All plugins will use your context then, this is the way AIO foresees it. This is also the reason they store it locally in the current directory only, to not have a global effect. The documentation just got published a few minutes ago, see https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments#installing-the-rde-command-line-tools open the 'Follow this example to setup a local context for one of your RDE logins' details. Do you think this is enough? I tried to keep it compact.
With this limitation I don't see a use case any longer for custom IMS context name (as now everything is stored locally). Just use one dedicated directory per tenant and stick to the default IMS context name and just use it for one tenant in there. Just use a different directory with a different .aio
config file for another tenant. As then there is only one context stored anyways the name does not matter.
Similar to https://github.com/adobe/aio-cli-plugin-cloudmanager/blob/dc09c0b78b70d58bc9d0e4378fe33053b69bcdea/src/common-flags.js#L16 please make the
imsContext
configurable (which is currently hardcoded in https://github.com/adobe/aio-cli-plugin-aem-rde/blob/e60e09ec24d51ad1db11e3a44c8f32744ed8cedc/src/lib/base-command.js#L57) to easily switch between different service authentications.