Generate job UUID in start-proxy action - #4049
#4049Open
mbg wants to merge 9 commits into
maingithub/codeql-action:mainfrom
mbg/start-proxy/job-uuidgithub/codeql-action:mbg/start-proxy/job-uuidCopy head branch name to clipboard
Open
Generate job UUID in start-proxy action#4049mbg wants to merge 9 commits intomaingithub/codeql-action:mainfrom mbg/start-proxy/job-uuidgithub/codeql-action:mbg/start-proxy/job-uuidCopy head branch name to clipboard
start-proxy action#4049mbg wants to merge 9 commits into
maingithub/codeql-action:mainfrom
mbg/start-proxy/job-uuidgithub/codeql-action:mbg/start-proxy/job-uuidCopy head branch name to clipboard
Conversation
Use in `init` and `setup-codeql` actions
The `start-proxy` step precedes `init` in Default Setup
mario-campos
previously approved these changes
Jul 29, 2026
mario-campos
left a comment
Contributor
There was a problem hiding this comment.
One nit but otherwise makes sense and LGTM.
henrymercer
reviewed
Jul 29, 2026
Comment on lines
+64
to
+71
| /** | ||
| * Either creates a UUIDv4 for the analysis or retrieves an existing one from the | ||
| * environment and returns it. | ||
| * If a new UUID is generated, it is also exported as an environment variable. | ||
| */ | ||
| export function getJobUUID( | ||
| action: ActionState<["Logger", "ReadOnlyEnv", "Actions"]>, | ||
| ) { |
Contributor
There was a problem hiding this comment.
This means that if JOB_RUN_UUID is already set by another step for some reason, we'll use that rather than overwriting it. That is probably fine, but perhaps we should add the CODEQL_ACTION_ prefix to the environment variable to reduce the chances of this happening.
Comment on lines
+143
to
+144
| // Create a unique identifier for this run. | ||
| getJobUUID(actionState); |
Contributor
There was a problem hiding this comment.
Perhaps it would make sense to do this in createStatusReportBase so we don't have to remember to call this in every Action that might run as the first step.
| throw new Error(`Input required and not supplied: ${name}`); | ||
| }, | ||
| getOptionalInput: () => undefined, | ||
| exportVariable: () => {}, |
Contributor
There was a problem hiding this comment.
This seems like it could be surprising — it'll silently discard all env var writes, while getTestEnv preserves writes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
start-proxyaction precedes theinitaction in Default Setup, but a UUID for the analysis is only generated in theinitaction. That means that telemetry from thestart-proxystep is not easy to associate with subsequent steps in the workflow.This PR refactors the existing code that's duplicated across
initandsetup-codeqlinto a function, allows it to retrieve the existing job UUID from the environment, adds tests, and then uses the new function instart-proxy. This ensures that telemetry fromstart-proxyincludes a unique identifier and the same one is used for the rest of the workflow, while workflows that don't usestart-proxyalso still generate one ininit.Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
dynamicworkflows (Default Setup, Code Quality, ...).Products:
analysis-kinds: code-scanning.analysis-kinds: code-quality.Environments:
github.comand/or GitHub Enterprise Cloud with Data Residency.How did/will you validate this change?
.test.tsfiles).pr-checks).If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist