Allow workflow to be passed via an environment variable for default setup

[henrymercer]

The default setup workflow is not checked into the repository, but the Action relies on the workflow file to make features like reporting failed runs work. We'd like to move to a more robust method of making features like reporting failed runs work, but this is hard to do without making a breaking change to the workflow file, and we aren't currently in a good position to do that.

Therefore as a medium term solution, default setup will pass its workflow file to the Action via the CODE_SCANNING_WORKFLOW_FILE environment variable.

GitHub staff: see an example run and the resulting status page.

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]

Looks good and found the appropriate debug log in the internal run (2nd attempt) linked, but assume you want @Daverlo's 👀 too!

A couple of questions:

• will we add integration tests for default setup at a later point?
• do we want to add a changenote since this is user facing?

[henrymercer]

• will we add integration tests for default setup at a later point?

Yes! Tracking this internally.

• do we want to add a changenote since this is user facing?

Good point, let's add a changenote for this.

[angelapwen]

Not sure why the PR check is failing though. Re-ran with debug mode.

Edit: looks like we might have a test flake, but because the re-run succeeded I'm not sure what it was!

[Daverlo]

LGTM!

[Daverlo]

What is this this returning when using default setup?

I don't think it really matters as I only see it being used for getting the analysis key, and for default setup we are always passing a category, so this value should be overwritten.

But I'm wondering if this should highlight that there is no workflow file somehow?

[henrymercer]

For default setup, this will return dynamic/github-code-scanning/codeql, but as you say we get the analysis key directly from CODEQL_ACTION_ANALYSIS_KEY. I think this is a good thing to highlight though, as this is part of some work I'd like us to do around nailing down in the code what context the CodeQL Action expects from default setup, in terms of the github job context, environment variables, etc.

[henrymercer]

At the moment, I don't think we want to fail if the workflow file isn't found — we want to preserve the way we've been generating the analysis key to avoid breaking advanced setups where the workflow file doesn't exist, e.g. reusable workflows or workflows executing in other repositories.