| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I think this is OK to merge if you are happy to break Rust analyses for those older versions of the CLI. See my thoughts in the comment I added. There's also one typo in the comment.
Sorry, something went wrong.
| // this point, if they want rust support they should chose a version which supports it | ||
| // publicly. |
There was a problem hiding this comment.
This might break Rust analysis for users who have pinned v3 (or similar) of the Action as well as a CodeQL CLI >= 2.19.3 && < 2.22.1 and who used CODEQL_ENABLE_EXPERIMENTAL_FEATURES. I agree that it's not unreasonable to ask users to upgrade to a newer CLI version in that case, but perhaps we should give them some warning first before breaking their workflows over night when the next Action release happens? That said, it's not clear to me that a warning in the output would necessarily be noticed. I don't know if we have any data to know how many people would be affected.
Sorry, something went wrong.
There was a problem hiding this comment.
in that situation (version 2.19.3..2.22.1 and CODEQL_ENABLE_EXPERIMENTAL_FEATURES=true) codeql resolve languages does give rust, which means that (await codeql.resolveLanguages()).rust is not undefined. The only change then is that users lose the Experimental Rust analysis enabled log line, but no functional change happens.
Sorry, something went wrong.
There was a problem hiding this comment.
uh, actually, now I see that that log line was dead code anyway!
Sorry, something went wrong.
Clarify comments regarding rust support in codeql versions
|
#3014 should ease the merge conflict in compiled code pain here. |
Sorry, something went wrong.
|
(Though we'll have to do the merge first, to get the updated workflow in the branch) |
Sorry, something went wrong.
|
I've noticed that #2914 duplicated the rust specific bock before initConfig. That got me thinking, that actually since the feature flag has been rolled out, the effective version from which we must support Rust to be backward compatible is 2.19.3, which means that we must set the env variable in versions between 2.19.3 and 2.22.1. I've changed the code accordingly in the if block before initConfig, and removed the later if block which becomes unneeded. |
Sorry, something went wrong.
There was a problem hiding this comment.
As I wrote elsewhere, I am a bit concerned that we have gone through a few iterations of the logic here, approved it, and then changed our minds about how this should work.
That signals to me that we:
Sorry, something went wrong.
| // Set CODEQL_ENABLE_EXPERIMENTAL_FEATURES for Rust. We need to set this environment | ||
| // variable before initializing the config, otherwise Rust analysis will not be | ||
| // enabled. | ||
| // Set CODEQL_ENABLE_EXPERIMENTAL_FEATURES for Rust if between 2.19.3 and 2.22.1 (excluded) |
There was a problem hiding this comment.
This is slightly ambiguous: does the "(excluded)" refer to both 2.19.3 and 2.22.1 or only the latter?
Sorry, something went wrong.
| // We need to set this environment variable before initializing the config, otherwise Rust | ||
| // analysis will not be enabled. |
There was a problem hiding this comment.
Could you add a small bit to this comment to remind us why it will not be enabled otherwise? I.e. is the logic for that elsewhere in the Action, the CLI, the extractor, ...?
Sorry, something went wrong.
| // Set CODEQL_ENABLE_EXPERIMENTAL_FEATURES for Rust if between 2.19.3 and 2.22.1 (excluded) | ||
| // We need to set this environment variable before initializing the config, otherwise Rust | ||
| // analysis will not be enabled. | ||
| // Initially this was driven by a feature flag which has been rolled out already. |
There was a problem hiding this comment.
Minor: This can probably be removed. I don't see much value in documenting what used to be the case here.
Sorry, something went wrong.
Also run the `rust` checks on "milestone" CLI releases, to ensure we remain backward compatible with those versions. This was prompted by #2960 (review) Running this on current `main` and then on that PR should improve our confidence we remain backward compatible. It also turns out a probable `ruamel.yaml` update was changing a lot of generated workflows, so I've: * fixed the `ruamel.yaml` version to the latest in `sync.sh` * added `yaml.width = 120` in `sync.py` to minimize (but not entirely remove) the number of changes * checked in the workflows whose formatting was changed by the new `ruamel.yaml` version
| /** | ||
| * Whether to enable experimental extractors for CodeQL. | ||
| */ | ||
| EXPERIMENTAL_FEATURES = "CODEQL_ACTION_EXPERIMENTAL_FEATURES", |
There was a problem hiding this comment.
ha, well, I should have double checked what copilot was writing here. Good thing someone suggested to put in more testing 😉
Sorry, something went wrong.
There was a problem hiding this comment.
(this was causing a failure in the 2.19.3 case, which is now fixed)
Sorry, something went wrong.
| logger.info("Experimental rust analysis enabled"); | ||
| if (semver.lt(actualVer, publicPreview)) { | ||
| core.exportVariable(EnvVar.EXPERIMENTAL_FEATURES, "true"); | ||
| logger.info("Experimental rust analysis enabled"); |
There was a problem hiding this comment.
Minor: Should "rust" be capitalised here?
Sorry, something went wrong.
There was a problem hiding this comment.
Makes sense
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Merge / deployment checklist