Add DOTNET_CI=true env variable to Apple and Android work item commands

[kotlarmilos]

Description

Sets the environment variable used by xUnit to detect if a test is running in a CI environment. This enables the SkipOnCI attribute to work correctly on Apple mobile and Android.

Fixes dotnet/xharness#1473

[Copilot]

Pull Request Overview

This PR adds the HELIX_WORKITEM_ROOT environment variable to both Android and Apple XHarness work item commands. This enables xUnit's SkipOnCI attribute to function correctly by providing the necessary environment variable that xUnit uses to detect CI execution environments.

Key Changes

• Added HELIX_WORKITEM_ROOT environment variable to Apple work item commands via --set-env parameter
• Added HELIX_WORKITEM_ROOT environment variable to Android work item commands via --set-env parameter

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
CreateXHarnessAppleWorkItems.cs	Adds HELIX_WORKITEM_ROOT environment variable to Apple XHarness command construction
CreateXHarnessAndroidWorkItems.cs	Adds HELIX_WORKITEM_ROOT environment variable to Android XHarness command construction

[kotlarmilos]

Is there a way to test this change in the runtime repository? I confirmed that the variable is relevant in dotnet/runtime#120671 and I would like to verify that this change is correct.

[premun]

@kotlarmilos possibly you can check the payload scripts of the Helix job sent in this PR and you will see where the envs went to.
You can then take a Helix job from runtime and replay it with the script files enriched with the vars to see what effect that will have.

[kotlarmilos]

Android doesn’t support the --set-env option (yet), so this PR updates only the Apple mobile command.

[premun]

@kotlarmilos alternatively, you could prepend all of the envs by default and then you wouldn't have to come back here once you find you also need the correlation payload path or any of the others

[kotlarmilos]

Do you mean a list like this?

  "--set-env=HELIX_CORRELATION_ID=\"$HELIX_CORRELATION_ID\" " +
  "--set-env=HELIX_CORRELATION_PAYLOAD=\"$HELIX_CORRELATION_PAYLOAD\" " +
  "--set-env=HELIX_PYTHONPATH=\"$HELIX_PYTHONPATH\" " +
  "--set-env=HELIX_WORKITEM_FRIENDLYNAME=\"$HELIX_WORKITEM_FRIENDLYNAME\" " +
  "--set-env=HELIX_WORKITEM_ID=\"$HELIX_WORKITEM_ID\" " +
  "--set-env=HELIX_WORKITEM_PAYLOAD=\"$HELIX_WORKITEM_PAYLOAD\" " +
  "--set-env=HELIX_WORKITEM_ROOT=\"$HELIX_WORKITEM_ROOT\" " +
  "--set-env=HELIX_WORKITEM_UPLOAD_ROOT=\"$HELIX_WORKITEM_UPLOAD_ROOT\" " +
  "--set-env=HELIX_DUMP_FOLDER=\"$HELIX_DUMP_FOLDER\" " +
  "--set-env=HELIX_CURRENT_LOG=\"$HELIX_CURRENT_LOG\" " +

I prefer being selective and passing only the required env variables instead of all of them. It requires some additional effort, but it gives a better sense of control and visibility over what is being passed.

[premun]

Do you mean a list like this?

I meant more dynamically reading the envs in the payload script and passing that down to the app. Not before creating the job.
But if we don't care for the value, I think Vitek's direction is better.