- changed status to open
Support global target-org config value
We recently implemented scratch org pools CI/CD pipelines and developers (two separate pools). We have a script for “claiming” a developer scratch org, and by default that script sets the scratch org as the global target-org.
In our monorepo we have 40 folders (DX packages) that are imported as IC2 modules. When I switch to a new scratch org in the IDE (and then close and re-open the project), it appears that IC2 executes a command for each module to set the local target-org to the same value already set globally.
The ask here is to support using the global target-org value when set and correct. For example:
- Have a configuration setting to disable the use of local target-org. Then when there’s a mismatch between the global target-org and the currently active scratch org, prompt the user to update the global target-org setting.
- If the global target-org is set to the same org that the local org would be set to, skip the setting.
Comments (3)
-
repo owner -
repo owner Mark, I’m pretty sure I know what’s going on here. IC is still using
sfdx
commands, and when it sets the default username, it does so in.sfdx/sfdx-config.json
asdefaultusername
. I’m guessing that you’re setting it usingsf config set target-org=...
which stores it in.sf/config.json
astarget-org
. That’s why it’s not seeing those values. The good news is that I’m updating IC right now to use the newersf
commands, and as a result, the logic for the dry run check for these types of config values. If all goes well, those changes will be included in next week’s build. -
repo owner - changed status to resolved
I'm pretty sure that this should be fixed as of 2.3.0.6 with the migration to
sf
CLI commands and IC2 looking at how/where those commands store the target org values. Feel free to reopen if you're not seeing the same after updating. - Log in to comment
I'd probably need to see a debug log of this with debug logging enabled for:
The reason is that IC already looks first at
<projectDir>/.sfdx/sfdx-config.json
, then looks at~/.sfdx/sfdx-config.json
before running the CLI to get that information. It also checks those files one more time immediately before running the CLI to set that information to see if perhaps it's already been set on another thread since being requested. As a result, it already supports user-level configuration of that value, and it shouldn't try to use the CLI to set it if already set in either location. Hopefully a debug log would show why it's doing so, though.