Cache CLI version information across Actions steps - #3943
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Pull request overview
This PR persists CodeQL CLI version information across GitHub Actions steps (via an exported env var) so later steps can reuse it instead of repeatedly invoking codeql version, reducing JVM startups and CLI calls.
Changes:
- Persist { cmd, version } into CODEQL_ACTION_CLI_VERSION_INFO when first computing the CLI version.
- Teach getVersion() to reuse the persisted version info keyed by CLI path.
- Avoid re-running the CLI for printVersion() by logging the cached getVersion() result.
| File | Description |
|---|---|
| src/util.ts | Adds persistence of version info via env var and enables cross-step reuse. |
| src/util.test.ts | Adds unit tests for reusing/ignoring persisted version info. |
| src/environment.ts | Introduces EnvVar.CODEQL_VERSION_INFO for cross-step persistence. |
| src/codeql.ts | Switches version lookup/printing to reuse cached/persisted version info. |
| lib/entry-points.js | Generated build output updated to reflect the TypeScript changes. |
Copilot's findings
- Files reviewed: 4/5 changed files
- Comments generated: 3
Sorry, something went wrong.
mario-campos
left a comment
There was a problem hiding this comment.
Some minor nits, but overall LGTM!
Sorry, something went wrong.
| return undefined; | ||
| } | ||
| if ( | ||
| typeof persisted?.version?.version !== "string" || |
There was a problem hiding this comment.
Nit: I think this would be a bit more readable as a type predicate:
| typeof persisted?.version?.version !== "string" || | |
| isPersistedVersionInfo(persisted) || |
Where isPersistedVersionInfo is defined as:
function isPersistedVersionInfo(x: unknown): x is PersistedVersionInfo {
return typeof (x as any)?.version?.version === "string" &&
typeof (x as any)?.cmd === "string";
}
Sorry, something went wrong.
| ); | ||
| } | ||
| util.cacheCodeQlVersion(result); | ||
| util.cacheCodeQlVersion(cmd, result); |
There was a problem hiding this comment.
There's a hypothetical "risk" here that a subsequent step/process may be inefficiently and repeatedly parsing the CODEQL_VERSION_INFO environment variable if the process calls getVersion() more than once.
The reason being that when getCachedCodeQlVersion() parses CODEQL_VERSION_INFO it does not store that result in the local variable cachedCodeQlVersion. That variable is only assigned when result === undefined—i.e.cachedCodeQlVersion is undefined and CODEQL_VERSION_INFO is unset/invalid—which is the first time that getVersion() is ever called.
Of course, this is all hypothetical because I don't think getVersion() is called more than once in the same step/process. And, it's probably a small penalty because it probably wouldn't take much time to parse the output of codeql version. But, the possibility would exist.
One option could be to always call cacheCodeQlVersion(...) just before returning from getVersion():
if (result === undefined) {
...
}
util.cacheCodeQlVersion(cmd, result);
return result;
Sorry, something went wrong.
De-ASI-INTERFACE
left a comment
There was a problem hiding this comment.
Thank you !
Sorry, something went wrong.
Persist CLI version information across Actions steps to avoid calling codeql version in each step. This saves 3 to 6 calls (and associated JVM startups) in a typical analysis job.
We use the path to the CodeQL CLI as a cache key. This is robust to setting up a different CLI with init or setup-codeql in the same job, but if a user hotswaps the CLI with a different mechanism and keeps the path the same, we are going to have the wrong version information. That seems like a rare enough case to be acceptable, but if we care about this, we could introduce more data into the cache key (at the cost of some performance).
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
Products:
Environments:
How did/will you validate this change?
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