Support global target-org config value

[Mark Mindenhall]

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:

1. 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.
2. If the global target-org is set to the same org that the local org would be set to, skip the setting.

‌

[Scott Wells]

I'd probably need to see a debug log of this with debug logging enabled for:

com.illuminatedcloud.intellij.sfdx.util.SfdxUtil
com.illuminatedcloud.intellij.util.IcProjectUtil

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.

[Scott Wells]

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 as defaultusername. I’m guessing that you’re setting it using sf config set target-org=... which stores it in .sf/config.json as target-org. That’s why it’s not seeing those values. The good news is that I’m updating IC right now to use the newer sf 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.

[Scott Wells]

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.