* A unique workflow file has been created merging all `swift-*.yml`
workflows
* Change filtering at job level was added using [dorny/paths-filter][1]
* only one build of the extractor is made, and then shared via cache
(not as an artifact because of [this longstading issue][2])
* integration tests are now run on on macOS
* qltests are not run any more on macOS to cut on feedback time
* autobuilder tests were moved to the macOS build step to avoid loading
bazel twice
[1]: https://github.com/dorny/paths-filter#examples
[2]: https://github.com/actions/upload-artifact/issues/38
if `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER` env variable is set, and either
* `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER_FILTER` is not set, or
* it is set to a regexp matching any substring of the extractor call
then the extractor process is substituted with the command (and possibly
options) stated in `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER`, followed by the
system arguments of the extractor itself (which should include the
extractor program itself at the start).
Before calling `exec`, `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER` is unset to
avoid unpleasant loops.
An example usage is to run the extractor under `gdbserver :1234` when
the arguments match a given source file.
With the change to `std::filesystem` some path concatenations were
translated to appending, which is not the same. In case rhs is absolute
`lhs / rhs == rhs`, while concatenating treats `rhs` as if it was
relative. The same behaviour can be obtained in `std::filesystem` by
using `lhs / rhs.relative_path()`.
Now that the released CLI supports replacement variables in dependency version ranges, we can now mark our published library packs as depending on whatever version of their dependency is in our workspace, without having to manually bump the dependency version every release.
Note that when the packs are published, the dependencies in the published pack file are rewritten to have the correct specific version.
