[DRAFT] Investigate PR Checks when feature flags are on

[angelapwen]

We observed some test failures on main after our Go extraction reconciliation feature flag was flipped on internally. We've disabled the flag; this PR overrides the feature flag's actual value to always return true, so we can investigate the test failures here.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[angelapwen]

The test failures I'm investigating are in PR Check - Test unsetting environment variables (the other two failures are linting errors caused by forcing the return value of the feature flag getValue method to be true.

My first instinct was that perhaps because this check unsets environment variables, something went wrong with the environment variable we had added (CODEQL_ACTION_RECONCILE_GO_EXTRACTION). But this doesn't seem to make sense, as this variable is only checked in the autobuild action, which completes successfully in the failing run.

I compared a run where the flag was enabled and a run where the flag was disabled outside of this PR.

When the flag is disabled, there is a log showing that Go is 'extracted' similar to a scanned language. With the flag enabled, the log section shows that we are attempting to autobuild Go (as expected). This seems to complete successfully, with no differences between the autobuilding logs compared to the Go "extraction" logs previously (which also ran the autobuilder).

Then, when the flag is enabled, the database finalize command for Java fails with

No source code was seen during the build.
  This can occur if the specified build commands failed to compile or process any code.
   - Confirm that there is some source code for the specified language in the project.
   - For codebases written in Go, JavaScript, TypeScript, and Python, do not specify 
     an explicit --command.
   - For other languages, the --command must specify a "clean" build which compiles 
     all the source code files without reusing existing build artefacts.

I thought this was pretty odd but don't see anywhere where we are affecting the Java source code (or anything in the Java database path) with Go autobuilding in the logs. Will continue to investigate.

[angelapwen]

When I commented out the fallback autobuild Go step in analyze, I receive:

• some linting failures because of uncalled methods (expected)
• a PR check failure when we did not run the autobuild fallback and didn't extract Go code (also expected, this does not fail when the logic is uncommented)
• the same PR check failure where Java is unable to be finalized.

This suggests that the failure is coming from the tracing steps themselves and unrelated to the fallback Go autobuilder.

[angelapwen]

Closing — solution to the problem in #1269