PP Checker 2.0.49 uses wrong resource principal (in GCC) when configured to save files.

[ToddShelton]

Environment: GCC.
Setting SaveResults: true seems to break the task by causing the checker service endpoint to default to https://gov.api.advisor.powerapps.com/ (note incorrect url for gcc), even when CustomPACheckerEndpoint: 'https://gov.api.advisor.powerapps.us/ should override it. After unsetting SaveResults from the task interface (deletes the YAML entry) the task runs correctly.

I have not tested this outside GCC.

REPRO:

1. Configure an application registration in AAD per .
2. Create a service connection using the app reg from step 1.
3. Configure a pipeline in GCC.
4. Add necessary initializations.
5. Export a suitable solution to a (pipeline) local location.
6. Add the PP Checker 2.0.49 task, configure it to use the service connection from step 2, the local location, and set SaveResult to checked (true in YAML).
7. Run the pipeline.
8. Observe Error: AADSTS500011: The resource principal named https://gov.api.advisor.powerapps.com/ was not found in the tenant...
9. Set SaveResult to false or unchecked and rerun the pipeline.
10. Observe correct behavior.

[tehcrashxor]

Confirmed that PAC has a wrong URL mapping to https://gov.api.advisor.powerapps.com/
Tracking internally as Bug AB#3812104

---

@ToddShelton, I expect that your successful run when SaveResult is false may actually be hitting the default public advisor URL. Please check your pipeline log for one of those successful runs; there should be a line Endpoint: [CheckerEndpoint] right above a line with Checking these solution files:

---

These ADO Tasks were designed for the old UI version of pipelines, so their behavior is not always obvious when in YAML.
The CustomPACheckerEndpoint value is only used when the task also contains a UseDefaultPACheckerEndpoint: false, as that second argument's default value is true if omitted. (Definition of these in this checker-v2/task.json file).

Unless you are also sending UseDefaultPACheckerEndpoint, the underlying PAC CLI will try to figure out which endpoint to hit, and the SaveResult will also send along context of the CRM Org URL inside the ServiceConnection. The bug mentioned above is from mapping that value (*.crm9.dynamics.com) to that incorrect endpoint.
When SaveResult is false, that extra context is not sent to PAC, so it (I expect) is hitting the default public endpoint.

Adding that UseDefaultPACheckerEndpoint: false to your YAML should work around the bug until we can get that fixed.

---

In the UI this task was designed for, this "Use default Power Apps Checker endpoint" box is checked by default and is the argument UseDefaultPACheckerEndpoint mentioned above

unchecking that box enables the Custom URL input

We should consider updating this task (or rather the underlying library) to not care about that switch, and just use the existence or not of the CustomPACheckerEndpoint to determine behavior.

[Yocomd]

We are also experiencing this issue. We already do have UseDefaultPACheckerEndpoint: false (and CustomPACheckerEndpoint: 'https://gov.api.advisor.powerapps.us/') in the YAML, so looks like there is no workaround for us?

[tehcrashxor]

Mapping was corrected in PAC v1.30.7, and in the just-released PPBT v2.0.52