We were ignoring errors coming from `vsce publish` and this was causing
the workflow to succeed even when the publish failed. This will remove
the `||` and let the workflow fail if the publish fails.
We introduced this change to help with reducing flakiness in CI [1].
This has a slightly different effect locally, where every failed test
will output three times.
This in turn makes it harder to read, especially when you have multiple
failing tests.
Since the original intent for this behaviour was to be used in CI, I'm
proposing we disable it when the CI env variable isn't set.
I've opted to set it for all jobs involving tests, just for consistency.
I'm happy to limit it to just the places where it's required.
[1]: https://github.com/github/vscode-codeql/pull/2059
This adds support for detecting the `CommandManager.execute` method in
the unique command use query.
This may not be the best way to implement this. There's a method
`hasUnderlyingType` on `this.getReceiver().getType()`, but I couldn't
really figure out how to get it recognize `CommandManager`. It might be
possible if we can construct the type of `CommandManager`, but this will
probably include the filepath to the `CommandManager` class, which might
not neccessarily be something we want: moving the `CommandManager` class
should not require updating the query. I'm very happy to hear other
suggestions.
This will upload the sourcemaps produced as part of the release as a
release asset. This allows the sourcemaps to be downloaded and used
for decoding stack traces beyond the 90 day artifact limit of GitHub
Actions.
Instead of using the third party `peter-evans/create-pull-request`
action for creating a PR for releases, we can use the already present
`./.github/actions/create-pr` action which is also used for the PR for
bumping CLI versions.
This commit adds a new step to the CI workflow that runs type checking
on all directories containing `tsconfig.json` files, using `find` and
`xargs`. Unfortunately, this does not work on Windows, so on Windows
it's not possible to run all of these type checks locally.
This adds a linter for JSON scenario files which will validate the JSON
files in the scenarios directory against the TypeScript types. It will
convert the TypeScript types to JSON schema to simplify this process.
Unfortunately, this will not currently allow adding scenarios with
failing requests since the types do not allow this. Rather than removing
this validation, we should fix the types. This can be done in a follow-up
PR.
- Avoid Installing `xvfb` since it is already available.
- Ensure `supportsNewQueryServer()` takes the CLI version into account
- Always run the new query server tests on v2.11.1 and later
- Avoid printing directory contents in `run-remote-query-tests`
- Run tests with `--disable-workspace-trust` to avoid a non-fatal error
being thrown from the dialog service.
- Ensure the exit code of the extension host while running integration
tests is the exit code of the actual process. Otherwise, there is
a possibility that an error exit code is swallowed up and ignored.
- Remove a duplicate unhandledRejection handler.
- Handle Exit code 7 from windows. This appears to be a failure on
exiting and unrelated to the tests.
- Fix handling of configuration in tests:
1. It is not possible to update a configuration setting for internal
settings like `codeql.canary`.
2. On windows CI, updating configuration after global teardown. So,
on tests avoid resetting test configuration when tests are over.
Also, I tried to remove all those pesky errors in the logs like:
> [2094:1017/235357.424002:ERROR:bus.cc(398)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
I was following advice from here, but I can't get it working.
- https://github.com/microsoft/vscode-test/issues/127
- https://github.com/electron/electron/issues/31981
The extension ms-vscode.test-adapter-converter is now available on
open-vsx, but under a different name.
Fixes https://github.com/github/vscode-codeql/issues/1085
I have verified that I can publish and install the extension by
manually publishing v1.6.4.
The Actions VM image containing v2.7.6 of the CodeQL CLI has now fully
rolled out, so we no longer need to download the latest CodeQL bundle to
use this CLI and include this repo in the ML-powered queries beta.