Do not artificially restrict the set of supported languages #779
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.
Description
The hardcoded set of supported languages in
languages.ts
makes it hard to experiment with new languages as custom branch with a modifiedlanguages.ts
is required for every new language.This PR makes it easier to experiment with new languages by making the
codeql-action
indifferent to the language choice, except for some additional support for known languages.Implementation
The old implementation throws an early error if the user-provided language is not in the hardcoded set. As an alternative, a
Language
is now just a lowercase string, and an early error is only produced if that language is not in the output ofcodeql resolve languages
. The oldLanguage
enum is now namedKnownLanguage
, and is used in the places where additional support for a specific language is desired.This should be fully backwards compatible, as the implementation now should throw an early exception in fewer situations. This may be detrimental to how early and well users are informed of input mistakes. On the other hand, it is consistent with how the provided
codeql
and environment behave.PMs may want to keep the tight coupling between the codeql-action and the GitHub-controlled CodeQL repositories, I do not.
Testing
I will use this branch for some internal experiments for a short while. Hopefully, the many changes wont result in too many conflicts when we are ready to merge.
Merge / deployment checklist