Store language aliases from linked CLI - #3806
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Pull request overview
This PR introduces a checked-in snapshot of CodeQL language aliases (sourced from the linked CLI) and switches the start-proxy Action to resolve language aliases from that snapshot rather than a hardcoded map.
Changes:
- Add src/known-language-aliases.json containing a snapshot of language alias mappings.
- Update src/start-proxy.ts to resolve aliases via the snapshot JSON instead of a hardcoded LANGUAGE_ALIASES map.
- Extend the “Update bundle” automation to refresh src/known-language-aliases.json from the released CodeQL bundle’s CLI.
| File | Description |
|---|---|
| src/start-proxy.ts | Uses the checked-in alias snapshot when parsing start-proxy language input. |
| src/known-language-aliases.json | New checked-in alias snapshot used by runtime code. |
| .github/actions/update-bundle/language-aliases.ts | New helper to download a bundle, run codeql resolve languages, and write the alias snapshot. |
| .github/actions/update-bundle/index.ts | Wires alias snapshot refresh into the update-bundle script alongside defaults update. |
| lib/start-proxy-action.js | Generated build output reflecting the TypeScript changes. |
Copilot's findings
- Files reviewed: 4/5 changed files
- Comments generated: 3
Sorry, something went wrong.
mbg
left a comment
There was a problem hiding this comment.
This looks fine, and thanks for simplifying! Fortunately, I hadn't reviewed those new scripts yet before you removed them.
One suggestion about typing known-language-aliases.json and performing the type checks statically, rather than dynamically.
Sorry, something went wrong.
| if (Object.hasOwn(KnownLanguage, language)) { | ||
| return language as KnownLanguage; | ||
| } |
There was a problem hiding this comment.
I think that this should be a given for the languages we have in known-language-aliases.json and shouldn't be checked here. (Instead we should check this at the time known-language-aliases.json is generated.) Adding a known-language-aliases.json.d.ts file with:
import { KnownLanguage } from "./languages";
declare const knownLanguageAliases: Record<string, KnownLanguage>;
export default knownLanguageAliases;can accomplish this. You may need to change the import here slightly and modify the github/filenames-match-regex eslint rule to accept .json.d. The code here then becomes:
// Check language aliases
if (Object.hasOwn(knownLanguageAliases, language)) {
return knownLanguageAliases[language];
Sorry, something went wrong.
There was a problem hiding this comment.
We filter the aliases down to the known languages to avoid a behaviour change in the start proxy Action, but I'm not sure if it's desirable in general to restrict to known languages. If we did want to, I like your solution. But I don't see the benefit of adding the restriction.
Sorry, something went wrong.
| - name: Update language aliases | ||
| env: | ||
| CODEQL_PATH: ${{ steps.setup-codeql.outputs.codeql-path }} | ||
| run: | | ||
| "$CODEQL_PATH" resolve languages --format=betterjson --extractor-include-aliases \ | ||
| | jq -S '.aliases // {}' \ | ||
| > src/known-language-aliases.json |
There was a problem hiding this comment.
This is simpler than the TS you had before, but does make it harder to perform the check I am proposing in my other comment. Though, we could just have a simple script which performs that check and runs after this.
Sorry, something went wrong.
|
I'll merge this as is, and make a followup PR implementing the improvements we've discussed offline. |
Sorry, something went wrong.
Add a checked-in snapshot of CodeQL language aliases (src/known-language-aliases.json) that is updated by the "Update bundle" workflow. This will have future uses, but for now we just update the start-proxy Action to use this instead of a hardcoded map.
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