* Fix freebsd CI build
This works around a bug in pot 0.15.4
Fixes#1529
* freebsd-ci: Add ca_root_nss package explicitly
+ It has been removed from curl as a dependency.
* Support FreeBSD as sccache-dist server
FreeBSD support makes use of [pot](https://github.com/potbsd/pot)
for sandboxing.
Implementation was done to be minimally invasive, almost all
FreeBSD specific parts happen in segregated files.
Co-authored-by: Sylvestre Ledru <sledru@mozilla.com>
Mental overhead is still too high due to the number of deps, many times the patch updates are edge cases being fixed that are not relevant to us, and effectively slowing down actual development.
Ref #1277 which assumed weekly would be ok, which it is not.
Modify Github Actions config to also create ZIP archives
Improve file handling in Github Actions releases
Signed-off-by: Emily Mabrey <emilymabrey93@gmail.com>
* Bump the MSRV to 1.58
Bumps the official MSRV to 1.58.
This is likely more than required the upcoming version bumps.
* Upgrade cargo zstd to 0.10
* Bump serial_test to v0.6
Changelog does not mention any breaking changes.
* Bump blake to v1
* Bump rouille to 3.5
Required to bump syslog to v6, since otherwise no common version
can be selected for `time`
* Bump syslog to v6
No changelog available. Depends on rouille bump to 3.5, to get a
common version of ´time´.
* Upgrade JWT to v8
The explicit insecure decode method was removed and replaced by
an option for the Validation struct.
The `exp` field had to be added to JobJwt, since otherwise the validation would fail at runtime.
Apparently the `exp` field is required now, even if the valdiation of `exp` is turned off.
* Add -fminimize-whitespace preprocessor flag when Clang >= 14 to increase cache hits
This proof of concept tries to take advantage of the new `-fminimize-whitespace`
preprocessor option in Clang. `-fminimize-whitespace` was added to Clang with the
intention to help increase the chance of a cache hit in tools like `sccache`
when only whitespace changes.
I also added a `version()` method to CCompilerImpl trait to expose the compiler
version to the preprocessor. This could be useful if version-dependent
features are added to `sccache` in the future.
Feedback on this is definitely welcome!
* Add tests for clang whitespace normalization
* Use clang -fminimize-whitespace to incread cache hits.
* Use ubuntu-22.04 for testing Clang 14
* Move compiler version from CCompiler to each CCompilerImpl.
* Use semver
Co-authored-by: Max Fan <root@max.fan>
Co-authored-by: Michael Kruse <sccache@meinersbur.de>
Previously, there would occur a mismatch on the GCC 9 version,
preventing us from installing it properly. Instead of that, try just
pulling GCC 10 rather than both 9 and 10.
* Refactor sccache cargo test
- Improve cleanup by using Result instead of panicking, to ensure that
the temporary folder gets cleaned up.
Previously, when a test failed, no clean up would happen. Now the cleanup
happens, unless there is an unexpected panic somewhere in the intergration test code.
- this commit aims to make it easier to add new tests
Split sccache cargo tests
To make it clearer what is failing, split the cargo test into multiple
tests. Since Sccache can't be invoked in parallel, we use the
`serial_test` to serialize testing,otherwise cargo by default would
start them in parallel.
The logger is now also lazily initialized, so the first test to run will
initialize it. It now writes a linebreak, because otherwise the output
is hard to read with
`RUST_LOG=debug cargo test --test sccache_cargo -- --nocapture`.
We catch panics (which are not intended by the tests ) to ensure that the
temporary directory for the test gets cleaned up.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Remove panic=abort from CI coverage test
I suspect the commandline was just taken like that from the example
here: https://doc.rust-lang.org/stable/unstable-book/compiler-flags/profile.html
However, there seems to be no reason to actually abort, since we don't have
a custom test harness or anything.
Since we want to catch panics, so we can correctly clean up, we need
panic=unwind.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
* Parse env_deps from dep-info
This will trigger rebuilds if environment variables changed that the rust code
depended on with env!.
On the Rust side this requires at least Rust 1.46, otherwise there will be
no env-dep info in the dep-info file. In that case we cannot detect
the dependency on the env-value, and behaviour is unchanged compared to
the current sccache behaviour.
With recent Rust versions however, we can trigger a rebuild if a variable
that is referenced via env! or option_env! is changed.
Other env variables like `CARGO_*` or `RUSTFLAGS` which may affect
the compilation are not listed in the dep-info file, so they have to
be blanket added (as is currently already the case).
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
* Add test for cargo env_deps
The previous commit added support for parsing "env_dep"
information from dep_info files. This commit adds a test
for changing an environment variable, that is referenced
in rust code via env!, and asserts that sccache rebuilds
and the rust code uses the new value of the changed
environment variable.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Bump the lint tests to use the current toolchain.
We don't want to use `stable` here, since that could cause CI failures
whenever a new rust version with new lints is introduced.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This includes:
- Building in release mode for all release platforms on all PRs and
merges/pushes.
- Publishing release assets on tags.
The extra benefit here is that the release assets are not pushed unless
all builds are successful, which was not the case before, leading to
0.2.13 without Windows binaries. We also make it necessary for all tests
and lints to pass.
Another benefit is that builds now have artifacts published, allowing
to download them for some period of time after they were produced on
a PR or on master.
The setup for musl-based builds suffers on arm64 from not being able to
build natively (per lack of arm64 runners), and from Ubuntu not having
musl-cross packages, so it requires a little manual (hackish)
cross-compilation work.
The Linux builds can safely be done on a newer version of the base
system as we are using the musl runtime, and compile openssl statically,
preventing any dependency on symbols from too new systems, ensuring
binary compatibility with older systems.
The macOS builds were done against Xcode 9.4 (the default on Travis),
which targets macOS 10.13. The 10.13 SDK is not available on Github
Actions, but we can set the deployment target to that value while using
the 10.14 SDK from Xcode 10.3 for binary compatibility. In theory, we
should be able to use an even newer Xcode/SDK, but I'd rather not risk
it at this point.
The Windows builds should have no binary compatibility issues.
On Travis, we used to build and run tests with both
--no-default-features and without, but without additional features, which
was the majority of cases, testing with --no-default-features was not
really useful, so we don't do that anymore, except for the dist-server.
Also, since dist-tests enables dist-server, the dist-server cases ended
up running the same tests multiple times, which we now avoid.
We also now split building the tests from running them, such that logs
can be a little easier to work with.
Github actions don't have arm64 runners yet, so we now don't run tests on
arm64 linux, but that's not expected to catch problems that wouldn't be
caught by the other tests.
The Appveyor setup was running tests with multiple versions of rust,
which is not done here, but that's not expected to catch problems that
wouldn't be caught by the other tests either.
And enable clippy, albeit allowing failures as the code is not
clippy-clean yet. We run clippy on all 3 main platforms because each
has platform-specific code that yields different warnings.
We explicitly disable two warnings:
- type_complexity, because it feels like unnecessary noise to try to fix
those before switching to async code.
- new-without-default, because I'm not particularly convinced.
Also stop running rustfmt on Travis.
Only actions from github (under github/ and actions/) are allowed, and
while actions from the mozilla organisation are technically allowed,
they're currently not meant to be, so use an in-tree action instead.
Even though Actions aren't supported on the main repo, they can still be
supported on personal repos, and people might proactively fix their
Windows bustage if GitHub sends them emails about it. So let's keep
Actions, but turn off things we haven't enabled on Travis yet.