For lasse #123

Solaris' GCC can't understand that our use is fine, unlike modern compilers: ``` list.c: In function 'print_totals_basic': list.c:1191:4: error: format not a string literal, argument types not checked [-Werror=format-nonliteral] uint64_to_str(totals.files, 0)); ^~~~~~~~~~~~~ cc1: all warnings being treated as errors ``` It's presumably because of older gettext missing format attributes. This is with `gcc (GCC) 7.3.0`.

Inspired by RsyncProject/rsync@3f2a38b. It runs on Solaris 5.11 via a VirtualBox VM.

xz is already part of oss-fuzz, but oss-fuzz provides & encourages [0] its 'CIFuzz' service to test individual PRs and commits. I think it can also run on a schedule but I haven't added that in (yet?) [0] https://google.github.io/oss-fuzz/getting-started/continuous-integration/

The only non-trivial part here was macOS where 'gcc' is actually Apple Clang by default, so we have to go out of our way to get GCC from Homebrew, and do the same for Clang.

This addresses the issue I mentioned in 6c095a9 and speeds up the Valgrind job a bit, because non-xz tools aren't run unnecessarily with Valgrind by the script tests.

Closes: tukaani-project#115

Without "set -e" the job will always be successful. See vmactions/freebsd-vm#72

Closes: tukaani-project#116

There's no real value in doing it via commit for official GH actions. We can keep using pinned commits for unofficial actions. It's hassle for no gain. Maybe going forward we can limit this further by only being paranoid for the jobs with any access to tokens.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

For lasse #123

For lasse #123

Commits on Jun 3, 2024