It turns out that the stale action is not able to delete its saved
state due to missing permissions. As a result, it was not processing
issues and PRs, that have been processed once, for almost a month.
The error in the job log was:
```
Warning: Error delete _state: [403] Resource not accessible by integration
```
The fix is to add `actions: write` to the action permissions
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add testing on pythong 3.14 and keep testing on python 3.13 for the
current stable Fedora version (42 at this time).
Use osbuild-ci:latest-202506112350 for tests.yml
Modify the action to allow passing the version when run manually. This
will be useful in the future once we branch-off a `rhel-x.y` branch to
backport a fix and will be doing the first "dot" release from such
branch.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The main reason is that it comes with license_expression python package
needed for newly added SBOM test cases.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Make sure that shell does not interpret the text within the back-quote
as a command to execute in a sub-shell.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add a simple script and an action to update images ref in Schutzfile on
schedule.
Both, the script and action are based on those in the osbuild/images
repository and the credit for those goes to Achilleas Koutsou.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Prior this commit, ${{ github.event.workflow_run.head_branch }} got
expanded in the bash script. A malicious actor could inject
an arbitrary shell script. Since this action has access to a token
with write rights the malicious actor can easily steal this token.
This commit moves the expansion into an env block where such an
injection cannot happen. This is the preferred way according to the
github docs:
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable
The test_host.py:test_signals_on_separate_fd (and more) runs
itself but that run will happen without the tox env so a pip/tox
installed pytest will not be found, install the pytest package
as a workaround.
This commit adds a tiny smoke test that runs the unit tests as
a normal user on a regular github runner. This should ensure that
we catch issues like in osbuild#1936.
This will bring the latest image builds with new dependencies for unit
tests.
In addition, pin down the osbuild-ci-c*s container to a specific tag, to
ensure stability of the CI.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Instead of hard-coding the Python version that the installed
python3-dnf has been built against on the latest Fedora, read the
value from the osbuild-ci container. The container now has the version
written in /osb/libdnf-python-version.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
'dnf' Python package can't be installed using pip in the tox
environment. In order to test the code which uses it, we need to use the
system version. Our testing environment uses Fedora as the system,
therefore we can reasonably use the system version of 'dnf' only with
Python version which is on Fedora.
Enable site packages in tox for Python 3.12 when testing osbuild
internals.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
In the release loop upstream changes are merged to Centos every two
weeks. This creates a delay in error detection when new tests
being added upstream.
Running tests in Centos based containers on top of the upstream code
more frequently should speed up error detection.
This will include the latest osbuild-ci container changes from
https://github.com/osbuild/containers/pull/73
This includes a bunch of binaries that were missing and lead
to skpped tests.
In PR#1752 Florian noticed that `make_containers` is buggy [0] in
one specific testcase. However the GH actions did not trigger and
uppon inspection the test is skipped:
```
stages/test/test_container_deploy.py::test_container_deploy_integration SKIPPED [ 7%]
```
This commit adds `-rs` to get a summary why the tests are skipped.
This is useful in general, I suspect the test container might miss
podman but this commit will bring clarity.
[0] https://github.com/osbuild/osbuild/pull/1752#discussion_r1578294358
Run only two jobs in the GH runner for the unittest. The `test_stage.py`
because it takes a very long time and needs to run in parallel and
all the other tests.
This split avoid that we forget to add new unittests to the matrix
as we did before (see e.g. https://github.com/osbuild/osbuild/pull/1731)
and it will also enable the tests in:
- sources/test
- inputs/tests
- mounts/test
to run.
This will reduce the "granularity" of the test output a bit, in the
GH runner we only see two unit test matrix jobs now. However that
should not be too bad because the non-stage tests are really quick
to run.
Using an environ for passing the tests is a bit of a headache when
it comes to quoting which is important when trying to write something
like: `-k "not test_stages.py"`.
I (personally) also find it slightly nicer/more intuitive to be able to do:
```
$ tox -e py36 -- ./test/mod
```
compared to
```
$ TEST_CATEGORY="./test/mod" tox -e py36
```
The other tests have concurrency issues at the moment.
It seems in https://github.com/osbuild/osbuild/pull/1655 we lost
parallel running. The issue seems to be that `env` does not
actually define a shell environment but only a github environment.
This sets commit sets the shell env explicitly to unbreak us
again.
There are recent GH failures because the github cache action
complains:
```
Input required and not supplied: key
```
This is slightly odd as we did not provide a cache key before and
it was fine but *shrug*. We also don't really need a cache key,
we always get the same cache, osbuild is smart enough to figure
it out.
There were special cases in the workflow for only running specific
tests in parallel. However how that the test_assemblers parallel
runs are fixed [0] there is really no need for special cases anymore
and we can just run them all in parallel.
[0] https://github.com/osbuild/osbuild/pull/1641
The `test_assembler.py` hardcods some filesystem and partition
UUIDs. This leads to hard to diagnose test failures when the
test is run in parallel. The btrfs and xfs filesystem drivers
will see the same uuid for multi created images and error sometimes with
someting like:
```
Mar 06 10:22:54 top kernel: BTRFS error: device /dev/loop104 belongs to fsid aff010e9-df95-4f81-be6b-e22317251033, and the fs is already mounted, scanned by mount (123856)
```
Its a race that only happens when two images are checked at the
same time.
This commit fixes the issue by just using a randomized UUID in
the test_assemblers.py. It also re-enables running the test in
parallel (which make it run a lot faster, from 34min to 14min).
Before this commit GitHub Action runs that were triggered by a PR were
not canceled when updates were made to the same PR. This lead to even
more clogging of our pipelines and not enough runners being available.
This changes the behavior in a way that whenever a PR gets updated all
still-in-progress runs get canceled and new runs get spawned.
This pipeline tests:
1. If the PR description is not empty (blocking)
2. If the PR title follows our format (non-blocking)
`component: This is the change (JIRA-001)`
3. If 1. and 2. are True, it adds a 'best practice' label to the PR
The default overlayfs doesn't work inside the container runner which
causes the test to fail with
Invalid destination name
containers-storage:localhost/osbuild-skopeo-test-...:
'overlay' is not supported over overlayfs, a mount_program is
required: backing file system is unsupported for this graph driver
Changing the driver to vfs solves the issue.
With pytest 8.0.0 the `-k` option seem to have changed it's
behavior. Drop `-k` therefore.
Tests started to fail recently and it looks like this is because
pytest 8.0.0 changes the semantic of the `-k` option. We used
to pass `-k stages/test` but that seems to no longer work. So
pin pytest to the last good version until this is better
understood.
