If we're running on push, then we can reintroduce the logic that skips
running with `tools: latest` when it would be the same as running with
`tools: null`.
Add a separate job that analyses the multilanguage test repo's Ruby code.
For now, run this only with the latest released CodeQL build from defaults.json.
The cached builds and nightly builds don't support Ruby yet.
In future, we can update this and other PR checks to test a wider range of cases.
Moving the files into ../action was causing the job to fail because it couldn't find the test directory anymore. According to @adityasharad, these 'mv's should
not be necessary. Removing these means changing the path to the actions.
I'm also removing the 'config-file' input to keep the test minimal. I think this will mean that CodeQL will use the default query suite, so I hope that this doesn't change the results.
This input allows users to specify which packs to run. It works in
unison with the packs block of the config file and it is similar to
how `queries` works. They both use `+` in the same way.
Note that the `#TODO` in the pr check is still around, but the CLI
is available. I will remove the TODO in the next commit.
Create a prerequisite job that runs the init step twice, with `tools: null` and `tools: latest`.
Use the outputs of these steps to compare the two CodeQL versions.
Pass the list of distinct tool versions for the integration tests to use in their matrix strategy.
This avoids redundant test jobs when the default and latest bundles are actually the same version of CodeQL.
`~` is accepted by JSON but not by the Actions context language, so we use `null` to indicate the default version.
Always test against both the default and latest CodeQL bundle.
This improves test coverage shortly after a CodeQL bundle release, where the latest bundle
may not yet be built into the Actions VM image as the default bundle.
It also saves a manual step during bundle release testing,
since we no longer need to temporarily change the PR checks to `tools: latest`.
There is some redundancy when the latest bundle is the same as the default bundle on the VM image,
but this can be considered a test for the `tools: latest` configuration.
These had some minor overlap checking that the JS is up to date and
there isn't any benefit in having them separate as the jobs are run in
parallel anyway.
