Do not use reupload_on_changes, this will make the cache grow unbound
and I have seen the cache become so large then restoring it and
uploading it took several minutes thus making the task time worse
compared to no cache. I manually cleaned the cache a few times to fix
this but it need to properly be fixed here.
To not have a stale cache for to long also use date +%U which will
create a new cache once a week. This is in line with the offical
golangci-lint github action which invalidates the cache every 7 days by
default[1].
[1] https://github.com/golangci/golangci-lint-action/blob/main/README.md#cache-invalidation-interval
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The winmake target is critical for the machine task as this is used to
actually run the ginkgo command line. PR #26847 modified that line will
not actually running the tests which means it is easy to break CI with
this. Now the chnage of the PR was correct so it worked fine this time
but for the future make sure we actually run the tests in such cases.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
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>
