Use GitHub Actions diagnostics flag in CI

[Arlodotexe]

Using the guidance in https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging, this PR disables verbose diagnostic logging in CI except when "Enable Debug Logging" is checked on a rerun.

[Arlodotexe]

Found an issue:

The workflow is not valid. .github/workflows/build.yml (Line: 21, Col: 23): Unrecognized named-value: 'env'. Located at position 1 within expression: env.ACTIONS_RUNNER_DEBUG

Docs aren't specific about which variable this is stored in, a search on github suggested env but this seems to not be the case. Will try github instead.

[Arlodotexe]

Let's squash this one.

[Arlodotexe]

That's odd, the random test failure we usually only see on WinUI 3 has happened on UWP now:

The active test run was aborted. Reason: Unable to communicate with test host process.
Closing app with package full name '7af355f7-0c20-4a39-9b71-8cf779ccfa82_1.0.0.0_x64__1v6rh0sdhj24c'.
Results File: C:\a\Windows\Windows\TestResults\UWP.trx

The active Test Run was aborted because the host process exited unexpectedly. Please inspect the call stack above, if available, to get more information about where the exception originated from.
The test running when the crash occurred: 
ConvertersExperiment.Tests.Test_BoolToObjectConverter.Test_ConvertBackCollapseWithNegateTrue

Linking #347 and rerunning.

[michael-hawker]

So, can we test turning the flag on now that it has run first, where's the checkbox for that?

And then are the logs just the normal logs or are there extras elsewhere we should know about?

[michael-hawker]

Yeah, so was just checking, it shows up with a confirmation dialog for failed jobs:

And all jobs:

I'm going to cancel this current run, then re-kick it with the toggle enabled so we can compare the two runs and check it's working as intended. 😊

[michael-hawker]

Kicked off here: https://github.com/CommunityToolkit/Windows/actions/runs/9896968654 - looking good so far, will see if it picks that up from the env, will be nice to see that off by default to get some brevity back in our builds. We can at least use this to further tweak the amount of output we do too in the future. Nice!

[michael-hawker]

@Arlodotexe so I see the debug info from GitHub, but it didn't seem to enable the flag?

It also feels like even when it's off the msbuild details are pretty huge, should we be minimal by default and on normal or detailed or something when the flag is on?

[michael-hawker]

Hmm, doesn't seem to be picking it up, should it just be a straight ACTIONS_RUNNER_DEBUG or secrets.ACTIONS_RUNNER_DEBUG ?

[michael-hawker]

Oh, just found this, it may just be ${{ runner.debug }} https://stackoverflow.com/questions/75434105/how-to-determine-if-the-github-action-is-running-with-debug-logging-enabled

From runner context doc - https://docs.github.com/en/actions/learn-github-actions/contexts#runner-context - this seems to be what corresponds to the checkbox. Not sure what that other doc is about...

We should update the comment too

[Arlodotexe]

Looking at the originally linked docs, I think I see why ACTIONS_RUNNER_DEBUG didn't enable verbose logging. From the docs:

Runner diagnostic logging provides additional log files that contain information about how a runner is executing a job. Two extra log files are added to the log archive:

• The runner process log, which includes information about coordinating and setting up runners to execute jobs.
• The worker process log, which logs the execution of a job.

Maybe we need to enable step debug logging instead via ACTIONS_STEP_DEBUG, which:

• increases the verbosity of a job's logs during and after a job's execution.

As for the runner.debug context value, the docs for this seem to point to the same docs used before 🤔

We can try both, but let's start with ACTIONS_STEP_DEBUG and see if that works.

[Arlodotexe]

Suggested change

	ENABLE_DIAGNOSTICS: ${{ github.ACTIONS_RUNNER_DEBUG }}
	ENABLE_DIAGNOSTICS: ${{ github.ACTIONS_STEP_DEBUG }}

[Arlodotexe]

Looks like ACTIONS_STEP_DEBUG didn't do it either, let's try runner.debug then

[Arlodotexe]

Posted here as well, but runner.debug didn't work as expected. runner isn't recognized.

[michael-hawker]

@Arlodotexe WinUI 3 tests failed, I'll ask some folks what we can do or who we can ask for more assistance in root causing that for them.

Doesn't look like that flag did anything, though not sure if once checked it remains checked? Or did you kick off a run with it?

Otherwise, we should try the other runner context

[Arlodotexe]

That's odd, I guess docs are outdated? Error message from last run:

[Invalid workflow file: .github/workflows/build.yml#L23](https://github.com/CommunityToolkit/Windows/actions/runs/10085654064/workflow)
The workflow is not valid. .github/workflows/build.yml (Line: 23, Col: 23): Unrecognized named-value: 'runner'. Located at position 1 within expression: runner.debug

[michael-hawker]

Maybe this is only available in the jobs section where the runner is used? As maybe it's per runner of a job vs. the whole workflow right? Otherwise, we should open an issue on https://github.com/actions/runner/issues as it's clearly listed in the documentation, just not with a great example...