A simple test to make sure that our btrfs stages work.
Updating the testing container is needed, because the old version
didn't have btrfs-progs in it.
This pulls the list of snapshots from the rpmrepo API, greps the
codebase for all uses of rpmrepo.osbuild.org that look like a snapshot
name, and then checks to make sure they are still valid.
This is the same script as osbuild-composer, except that it also skips
checking ./test/data/stages/ which has rpm urls that look like snapshot
urls.
`tox` is a standard testing tool for Python projects, this allows you to
test locally with all your installed Python version with the following
command:
`tox -m test -p all`
To run the tests in parallel for all supported Python versions.
To run linters or type analysis:
```
tox -m lint -p all
tox -m type -p all
```
This commit *also* disables the `import-error` warning from `pylint`,
not all Python versions have the system-installed Python libraries
available and they can't be fetched from PyPI.
Some linters have been added and the general order linters run in has
been changed. This allows for quicker test failure when running
`tox -m lint`. As a consequence the `test_pylint` test has been removed
as it's role can now be fulfilled by `tox`.
Other assorted linter fixes due to newer versions:
- use a str.join method (`consider-using-join`)
- fix various (newer) mypy and pylint issues
- comments starting with `#` and no space due to `autopep8`
This also changes our CI to use the new `tox` setup and on top of that
pins the versions of linters used. This might move into separate
requirements.txt files later on to allow for easier updating of those
dependencies.
The test case was testing a subset of the functionality, which is
already tested by test case in `tests.yml`. Delete it, since it does not
add any value.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
In CI, we list specific tests from `test/run` to run them in parallel.
This is different than what we do with tests in `test/mod` and
`test/src`.
It seems that as a result, we did not run tests from the following
files in CI:
- `test_devices.py`
- `test_mount.py`
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add a bot to update the SHA dependency to OSBuild on manifest-db
automatically.
The OSBuild SHA will be changed only if the manifest-db SHA was updated
on the last commit landed on main. This way this ensure that CI ran
successfully for this exact version of OSBuild against manifest-db's
actual state. Therefore it is safe to assume that we can upgrade the
manifest dependency without running the whole CI again.
Update the osbuild-ci container and privdocker action to the most recent
builds.
This changes the ostree-image-tests since the Fedora update pulled in
util-linux/fdisk changes that align partition sizes. Hence, the ostree
tests need to be changed to have aligned partition sizes as well. For
more information, see:
commit 921c7da55ec78350e4067b3fd6b7de6f299106ee
Author: Karel Zak <kzak@redhat.com>
Date: Thu Jan 27 10:50:45 2022 +0100
libfdisk: (gpt) align size of partition by default
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
Add to new autopep8 check to the checks suit. Ideally we would
move the `test.src` test over from tests.yml, but running that
in an updated container leads to a whole lot of new warnings,
most of them related to "unspecified encoding" in `open` calls.
Adjust the timer for our automated releases to trigger the workflow at
8 UTC. This corresponds to 10am in most of our team's timezone and to
the reminder event in our team calendar.
Instead of a human pushing a tag with the release notes let a bot do the
work.
The bot is part of our composite action in osbuild/release-action on the
create-tag branch. It calculates the next subsequent release version and
creates a tag based on pull request titles associated with the changes
since the last release.
Finally the tag is pushed to the repository.
Unfortunately GH Actions don't allow for reliably fortnightly schedules,
so we do an additional check that determines if this is an even or an
odd week. This will help with correctly scheduling alternating osbuild
and osbuild-composer releases.
For reference, we do exactly the same for osbuild-composer already:
https://github.com/osbuild/osbuild-composer/blob/main/.github/workflows/create-tag.yml
OSTree tests, especially the fedora-ostree-image one, will soon
need the tight integration with the host for LVM2/LUKS support.
This we cannot run them in github action containers. Move them
to Schutzbot.
Explicitly install the new sub-package until composer gains the
needed requirement.
Instead of using merify which seems to not do what we want, use
a combination of mergify and automerge. We let mergify review
dependabot PRs. We let mergify dismiss reviews on updates but
exclude those from Schutzbot. We then let Schutzbot update and
merge the PRs via automerge if the `ci:automerge` label is set.
We need a privileged / admin user doing the post-release version bump as
this is a direct commit to main (i.e. without a PR) so switch to using
schutzbot with a scoped personal access token (only public_repo).
This is necessary for the new simplified release process and is done
ahead of time once for the upcoming release now.
After osbuild 40 this will be done by the GitHub composite action.
This commit changes our release process from the model of having a
release commit (and pull request) which also updated the NEWS.md file
and bumped the versions in the osbuild.spec and setup.py files to simply
pushing a tag.
After the tag (containing the release notes) is pushed, a GitHub
composite action is triggered that creates a GitHub release with the
contents of the git release tag. Furthermore the bumping of the version
number now always has to happen directly after a release to avoid having
to push a(n untested) commit to main for the release and this is also
handled by the GitHub composite action.
Finally packit pushes directly to dist-git now on pushing the release
tag, so no pull-request needs to be reviewed and merged anymore.
Use the "Checks" workflow to trigger gitlab; this workflow should
be much quicker to complete and thus the gitlab ci will trigger
earlier leading to a more parallel ci run.
Sadly `github.event.workflow_run.pull_requests` is empty if the pull
request was opened from another fork. Use the sha to find an open PR,
otherwise assume it's a branch.
This workflow doesn't have access to the original pull request event
that resulted in this workflow being triggered.
Simply use `head_sha` which will contain the PR sha if it was triggered
by a PR's workflow, or the branch sha if it was triggered from a
branch's workflow.
The `workflow_run` event is triggered either when a workflow was
requested or complete (see `types`). We can use this event as a
trigger for the gitlab ci conditioning on a successful workflow
run of the main tests ("Tests" workflow). This will ensure that,
with outside contributor protection turned o, no secrets are
leaked via PRs from non-contributors, but also that gitlab ci is
run for those PRs once they were manually allowed to run.
The only downside is that now the gitlab ci will only run after
the main workflow ("Tests) has completed and thus serializing
both CI runs. OTOH gitlab CI is quite intense so maybe this is
not so bad after all. If in the future we want to parallelize
both CI runs we could have a third "precheck" condition with
maybe the spell checker and the pylint tests that the main tests
as well as the gitlab ci run depend on.
Instead of maintaining a separate set of samples that by now are very
much outdated (using Fedora 31 or older), make the samples directory
a symlink to the test data. Manifests in there are indeed tested and
maintained.
The error and noop samples are also covered in unit tests, so no need
for extra samples there either.
CI: remove the sample validation since all the test data manifests
are actually built.
Add new `org.osbuild.cloud-init` stage, which currently allows to create
configuration files for cloud-init under `/etc/cloud/cloud.cfg.d`. The
stage supports only a very limited subset of cloud-init configuration
options, which is covering needs of RHEL AMI images.
The schema mandates that if the 'configuration_files' option is
specified, then at least one configuration file must be defined. In
addition each section of the configuration must contain at least one
property (section or configuration option).
Add `python3-pyyaml` package to the `F34-build` testing manifest,
because it is required for running and testing the new stage.
Regenerate all affected manifests.
Add test for the new stage.
Update the `osbuild-ci` container image used for testing to a new tag,
which includes python3-pyyaml, the dependency of the new stage.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
