Both `copyNoWorkspaceData` and `copyCliIntegrationData` return
promises. Since file copy-ing is quite fast at the moment, this
hasn't been a problem, but it might become a problem in the future
if we start copying larger files.
Let's wait for the operations to finish.
Now that we have a watch command to check when our test files
need updating, we don't need to do this step during the setup.
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
Because we're no longer running `gulp` when we run our test command,
we're going to need a way to update our test files when they change.
This will watch for any changes in our test files and copy the new
version over.
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
We previously attempted to speed up no-workspace tests [1] but realised
we still needed to run some setup steps to get the latest files [2].
Given that we already have `npm run watch` running in the background
when we run our tests, we should be able to regenerate files on the fly.
This means we can drop `gulp` from our setup steps when running integration
tests.
While there's still a danger that you forget to run `npm run watch` in
the background, we think the massive speed up (10s -> 1s) is worth it
as we add more and more tests to this extension.
[1]: https://github.com/github/vscode-codeql/pull/1694
[2]: https://github.com/github/vscode-codeql/pull/1696
The `not_found_repo_nwos` field doesn't actually exist (anymore?) on the
GitHub API. The correct name is `not_found_repos`, so this renames the
field on the type and in the scenarios.
The `createGist` functionw was part of `gh-actions-api-client`, while it
didn't actually involve anything related to the GitHub Actions API. This
moves it to the non-Actions-specific `gh-api-client` module.
Another candidate for moving to `gh-api-client` is
`getRepositoriesMetadata`, but that one is a bit more involved since it
uses `showAndLogErrorMessage`, so depends on the `vscode` module. This
means it would not be possible to test in the "pure" tests and we would
need to move all our `gh-actions-api` tests to the integration tests. It
will not be used for variant analysis queries anymore, so I don't think
it's worth moving or refactoring to not depend on `vscode`.
This will hook up the "View logs" link to make it open the variant
analysis actions workflow run. The method for creating the actions
workflow run URL has been extracted from the query history to make it
callable without a history item.
This adds the `controllerRepo` field to the `VariantAnalysis` shared
type. This is technically a breaking change since the old history won't
have this field and all calls on this will fail. However, the feature
is not available so this should be fine.
This wil remove the discrepancy between the files on which ESLint is run
when `lint-staged` is used and the files that are checked using
`npm run lint` and `npm run format`.
It will now also include the `.storybook` directory which was previously
excluded from the ESLint configuration.
This will make the creation of a webview panel async to allow the
`getPanelConfig` method to be an async function. This will allow us to
do some work (like retrieving the variant analysis) in the
`getPanelConfig` method.
