This shaves the linting time:
- from 8 to 2 minutes on Cirrus CI with 4 CPUs and 8 GB RAM;
- from 11 to 3 minutes on Cirrus CI with 2 CPUs and 4 GB RAM;
when the cache is reused.
The cache size is quite modest (~3MB compressed, ~7MB uncompressed).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This could have been done by simply running
GOOS=freebsd ./bin/golangci-lint run [options] ./...
on Linux, but some freebsd code is using cgo (i.e. is linked to C
libraries), so real freebsd environment is required.
This also fixes the issue of ignoring linter errors for Windows and
Darwin (exit 0), introduced by commit c9b108d5b38.
Fixes: c9b108d5b38 ("Bump golangci-lint to v2.0.2")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This shaves off some time from golangci-lint run.
For linux, it's down from 5 to 3 minutes (for the whole task, not just
the golangci-lint runs), and the cache is only ~7MB (according to
golangci-lint, probably uncompressed) or ~2MB (according to cirrus CI,
probably compressed).
For Mac, due to remote build tag we don't lint much so linting takes
less than a minute, so it is not worth optimizing.
For Windows, similar.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This one has two local NVMe's attached so we should be able to use fast
local storage to hopefully speed the test up. The NVMe are not mounted
by default so we have to format and mount them. I have choosen Z as
drive letter as I guess it seems most likely that it is free.
Then we need to set the TMPDIR envs to make the machine tests use the
new location.
This speeds up hyperV tests by 20mins and wsl by 9 mins.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add a new target in winmake.ps1 to run unit tests and use
use it in a new cirrus task.
Fix machine_windows_test.go to make it work in CI machine.
Add the `!windows` tag on tests files that fail on Windows.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Like commit d03e8ffc56, we need to bump to go 1.23 to get some
dependency updates for CVE fixes.
Thus it will no longer build/test on F40, however F40 might get
rebased to go 1.23 soon then we can revert this.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As they run parallel now we can use some more cores and remove the long
timeout, they must be faster than the 20min default now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
They really should not take that long, however they timeout out more
often then they pass so let's give this is a try.
I have some hopes that the new worker pool from Adrian might perform
better.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We see a ton of timeouts in bot the applehv and libkrun machine tests.
It seems 35m are no longer enough. I was not able to spot anything that
would explain why it increased all of the sudden as such I hope this is
enough.
Fixes#25057
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
...for debugging #24147, because "md5sum mismatch" is not
the best way to troubleshoot bytestream differences.
socat is run on the container, so this requires building a
new testimage (20241011). Bump to new CI VMs[1] which include it.
[1] https://github.com/containers/automation_images/pull/389
Signed-off-by: Ed Santiago <santiago@redhat.com>
Accidentally introduced in #21639.
Thanks to Paul for the Python code to prevent this from
happening again.
Signed-off-by: Ed Santiago <santiago@redhat.com>
tar should be smart enough to check the magic byte and use the correct
decompression algo based on that so there is no need to spell it out
explictly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The repo tar process took over 1:20 min, with zstd it takes less than
10s so we safe over a minute by doing this.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Builds now take over 10 mins, given golang compilation is parallelized
by default we can give more cores to speed it up.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In order to get better debug data for cleanup flakes. The argv is
printed with 0 bytes so replace them with spaces to make the log
readable for humans.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
...and remove one old skip() for older debian, but leave
two others in place and mark that they're still a problem.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Minor bump. Fedora VMs now include ShellCheck, so we can
remove the 'dnf install' at CI run time.
Also, FWIW, Debian *vark are now at 1.12 (from 1.9)
VMs built in https://github.com/containers/automation_images/pull/385
Signed-off-by: Ed Santiago <santiago@redhat.com>
We want to update to golang 1.22 but f39 only ships 1.21. This means we
can no longer build on f39 once the update is done. Given we do not ship
podman 5.0 on f39 anyway this is not a problem.
So drop the f39 tasks but given we use them to test different db/storage
drivers we cannot just remove them. Instead we now test f40 twice with
the different db/storage drivers to ensure we keep full coverage.
It do however drop it from the container int task. I really do not see
the value there to test a different db backend as this doesn't depend on
anything in the container.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Since commit 26cd01ee51 we only test netavark and cni support was
dropped. Remove the leftover CI_DESIRED_NETWORK reference.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
They do not add much value to users, first of it compiles podman with
cgo disabled which means the included the podman binary is unusable
either way. The only goal of the build job is to ensure we can compile
on all arches, i.e. go build tags adn types work correctly. The upload
if these artifacts alone take over 90s so let's get rid of them to speed
up the total CI time.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is not used by anybody so we do not have to store these and can safe
some time by not having to generate it even if it is just ~500ms.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Two weeks ago we had a weird hang in the macos build job on the
persitent worker. The task just hang for an hour wasting time.
Most tests are fast so we do not need/want such high timeouts.
Therefore drop the default timeout to 20 minutes. The integration task
also should take under 20m so we can remove the longer timeout there as
well. Some system tests need a bit over 30m currently, timeout is set to
35m. For machine tests we use 30m on linux, 45m on windows and 35m on
macos to have some extra room there as machine tests have a much higher
run to run variance.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We already exclude the build jobs this is causing the machine tasks to
fail as noticed in #23764. Given we do not need windows/macos testing
for RHEL we have to skip them there.
While we try to only use only_if the problem here is that we would need
to duplicate the big only_if_machine_test string and work the rhel
condition into it which doesn't work with the current logic either so we
would need to change the logic flow there which then doesn't work with
our cirrus_yaml_test.py selftest. Therefore I think using skip here is
easier.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
