This has not seen any significant changes for years. So it lacks support
for modern algorithms and would require quite some work for an overhaul.
Given that we support several other crypto backends, let's just remove
this to reduce the maintenance burden.
The test scenarios and other references are also removed.
This does not seem to work on these runners. Tried setting
dataflowMemoryLimit, but that only seems to affect the analysis (which
causes a warning: "Taint analysis was stopped early due to low memory.
The analysis may not have explored the whole program.") not the
post-processing that evidently causes the runner to get killed due to
OOM (there is no explicit error, but in the debug log we see "The runner
has received a shutdown signal", which apparently can indicate OOM
issues).
We don't want to build old versions using these caches, so we don't
need old entries (if header files change, there could be lots of
differences that increase the cache size unnecessarily).
These are shared by many tests, in particular the "all", "coverage",
"no-dbg" and "no-testable-ke" tests, which each would otherwise require
their own large cache.
Similarly, the "codeql" and "sonarcloud" tests rely on the same
dependencies but only the latter uses ccache for the strongSwan build.
Also reduce the maximum size per cache for all workflows to keep them
in check over time (some could even be set lower, we'll have to see
how this develops).
As mentioned in the previous commit, ASAN does a fine job detecting leaks
during the tests. We just add a single LD-enabled build of the "default"
test here to test the basic functionality.
And we continue to use leak detective in our testing environment to keep
the memory requirements low.
We don't need a separate cache for the "apidoc" test and while the
"dist" test is similar as well, it builds in a different directory,
which means that config.h causes a cache miss for everything but the
configure checks.
The others are either included already in the "all" build (to which we
now switch) or they have a relatively small diff to that (e.g. gcrypt
only differs in that relatively small plugin). For the "openssl-sys"
build, we can rely on the "default" build but only on ubuntu-latest as
we don't build that on ubuntu-22.04.
Let's try this again :) Since cache entries with the same key are not
updated/replaced and there is no option to do so, we manually delete the
previous entry for the current branch.
This reduces the cache storage for active branches, which can cause
caches of the master branch to get evicted, which in turn will slow down
builds of not only master but also new branches as they can't fall back
on those caches.
Permission has to be explicitly granted in order to delete the cache
entries when not using the legacy all-write tokens that are the default
for old repositories.
The continue-on-error option is set for the step that deletes the old
cache entry as it's expected that cache-hit will be true for a new feature
branch when restoring the cache from the master branch. However, because
there won't be anything to delete for this branch yet, the command will
fail. The --succeed-on-no-caches option of the command unfortunately
only works with --all.
For the Linux tests, several jobs use the same cache key. So there is
a chance that two jobs try to store a new entry concurrently, which will
fail (it works if there was a cache hit and they are slightly off as
previous entries are first deleted). To avoid that, we store the cache
only for one particular config.
Also made sure that the "openssl" test does not remove "openssl-3/4"
caches by adding a suffix to the former.
For alpine, the repository had to be set explicitly as gh wasn't able to
determine it (didn't detect the Git working dir).
While continue-on-error can be configured more specifically (e.g. also
would allow to handle "default" and "printf-builtin" tests that rely
on debug symbols), it also lets the workflow succeed if any of these
jobs fail. That's not ideal if there is an actual error and not
just an intermittent package sync problem.
These are quite a bit faster than on AppVeyor (with ccache about a fifth,
without less than half - and they run concurrently).
We only keep the AppVeyor builds for now to test against those old
OpenSSL versions (1.1.1 and 1.0.2) for which there is still extended
support available. Even simplified like that they still take longer
than the builds on GA.
This reduces the cache storage for active branches and since caches for
different branches are separate and we abort previous builds of the same
branch, this is not necessary to ensure caches can successfully be stored.
The action causes errors because it is not compatible to the Docker
version used in the runner images. Unfortunately, it doesn't seem
maintained anymore. The action is simple enough, though, so instead of
switching to a fork, we just use "docker run" directly.
While macos-13 was running on Intel, both macos-latest (macOS 15) and
macos-14 run on ARM64. While there are Intel-based images for 14 and 15,
they will only be available until August 2027 (and there aren't any Intel
devices anymore anyway).
We explicitly pass the final .info file prepared with lcov, so there is
no need to search for other files (that then won't work anyway). The
search also finds the uncleaned .info file, which includes the test code.
The latter should have gotten ignored anyway, but the patterns are
apparently not correct anymore. So fixing that as well just to be sure.
AWS-LC is an OpenSSL derivative which can be used with the openssl plugin.
This adds a CI job that resembles the openssl-3 test case. It downloads
the source tarball for an AWS-LC release, builds that source using
CMake/Ninja, and then builds/tests strongSwan using the same technique
used by openssl-3.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2151
Also fix the path to the sdkmanager (the old one was removed in the latest
images and the incorrect path caused a weird sudo error) and install
Java 17 as that's necessary for newer versions of the Gradle plugin.
Tobias Brunner