|
17 | 17 | you know what to do). |
18 | 18 | --> |
19 | 19 |
|
| 20 | +## Release 2.7.5 (2022-01-17) |
| 21 | + |
| 22 | +- The bundled extractors are updated to match the versions currently |
| 23 | + used on LGTM.com. These are newer than the last release (1.28) of |
| 24 | + LGTM Enterprise. If you plan to upload databases to an LGTM |
| 25 | + Enterprise 1.28 instance, you need to create them with release |
| 26 | + 2.5.9. |
| 27 | + |
| 28 | +### Deprecation |
| 29 | + |
| 30 | +- The CodeQL Action versions up to and including version 1.0.22 are |
| 31 | + now deprecated for use with CodeQL CLI 2.7.5 and later. The CLI |
| 32 | + will emit a warning if it detects that it is being used by a |
| 33 | + deprecated version of the codeql-action. This warning will become a |
| 34 | + fatal error with version 2.8.0 of the CLI. |
| 35 | + |
| 36 | +### New feature |
| 37 | + |
| 38 | +- The `codeql github upload-results` command will now print the API |
| 39 | + response body in JSON format if a `--format=json` flag is |
| 40 | + given. Otherwise the command will print the URL of the SARIF |
| 41 | + upload. This URL can be used to get status information for the |
| 42 | + upload. |
| 43 | + |
| 44 | + See also: https://docs.github.com/en/rest/reference/code-scanning |
| 45 | + |
| 46 | +### Documentation fixes |
| 47 | + |
| 48 | +- The documentation for the `--trace-process-level` flag of `codeql |
| 49 | + database init` (which is used with indirect build tracing on |
| 50 | + Windows) was erroneous. |
| 51 | + |
| 52 | + The help text previously claimed that `--trace-process-level=1` |
| 53 | + would inject CodeQL's build tracer into the calling process. This is |
| 54 | + actually what `--trace-process-level=0` achieves. The help text has |
| 55 | + now been corrected to match the actual (unchanged) behavior. |
| 56 | + |
| 57 | + Also, some log messages incorrectly stated which process CodeQL was |
| 58 | + injected into. These have also been corrected. |
| 59 | + |
| 60 | +### Other changes |
| 61 | + |
| 62 | +- For commands that run queries, the `--timeout` option now controls |
| 63 | + the maximal time it may take to evaluate a "layer" of a query rather |
| 64 | + than a "stage". There are usually many "layers" in each "stage", |
| 65 | + but it is usually a single one of the layers in a stage that uses |
| 66 | + most of the time, so there is no need to reduce existing timeout |
| 67 | + values as a result of this change. |
| 68 | + |
| 69 | +## Release 2.7.4 |
| 70 | + |
| 71 | +This release was skipped. |
| 72 | + |
20 | 73 | ## Release 2.7.3 (2021-12-06) |
21 | 74 |
|
22 | 75 | - The bundled extractors are updated to match the versions currently |
|
0 commit comments