Brad Larsen

I looked at this issue again just now. Had trouble building out of the box with `cross`, and was unable to build successfully when setting `RUSTFLAGS='-C target-feature=+crt-static'` in the Alpine...

@SkyperTHC @Azathothas the next release will include prebuilt statically-linked releases for x86_64 and arm64 Linux. Previously, I had tried both `cross` and explicitly playing with static linking options, but ran...

Although GitHub has native ARM runners, it appears that they are still in private beta that you have to sign up for: https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/

We are now using the new Linux ARM64 runners for regular CI jobs and for building release artifacts: https://github.com/praetorian-inc/noseyparker/pull/197. (The runners that we set up for that are named `ubuntu-22.04-arm64-8-core`...

See this for requirements and suggestions related to GitHub Code Analysis SARIF support: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning

I asked for help in understanding how best to represent Nosey Parker's findings in SARIF: https://github.com/oasis-tcs/sarif-spec/issues/564

The caching also doesn't seem to be working as one would hope within the Docker image builder workflows. There, however, you have an additional caching mechanism to worry about beyond...

In #164, I've improved the caching situation in regular GitHub Actions some, giving a 30-50% reduction in build times when a cache hit occurs. To fix the caching problems in...

Note for Docker caching problems in CI: It looks like building the Debian-based Docker images does `apt install` every time instead of ever caching that layer, which invalidates everything following.

I recently [split out Vectorscan](#168) into its own published crate. Now in the CI jobs, that long-building package can be cached, and cached build job times are all under 2...