This commit introduces a new TMT tests and a GitHub Actions workflow to
run it.
TMT (Test Management Tool) is a tool for managing and executing tests
in a structured and efficient manner. It allows users to define test
plans, organize test cases, and execute them in a consistent manner. TMT is
particularly useful for testing software projects, as it provides a
framework for managing the entire testing process, from planning to
execution and reporting.
The workflow is set up to run on every push to the main branch and on
pull requests, providing continuous integration for the project.
The core test added is designed to verify the basic functionality of
the application using TMT, ensuring that it can successfully execute a
simple test case.
The smoke plan is defined in the `tests/tmt/plans/smoke.fmf` file and
is configure to run all tests with smoke tag.
The `tests/tmt/plans/main.fmf` file is the main plan that includes
common configurations and settings for the plans. Currently, it prepare
the test environment.
The workflow is defined in the `.github/workflows/tmt-tests.yml` file
and includes steps to set up the environment, install dependencies, and
run tests. It is allowed to execute on pull requests, pushes to the
main branch, and on demand. By default all tests are executed, but it
can be executed on demand with a TMT plan filter. As part of the
workflow, TMT will be executed inside a container.
JIRA: https://issues.redhat.com/browse/COS-2284
Signed-off-by: Tiago Bueno <tiago.bueno@gmail.com>
Move all field descriptions to a single YAML file and generate version-
specific spec docs from that. Use reflection to walk the config
structs for each version and omit fields which don't exist in a
particular spec version.
We don't do this at a JSON Schema level because e.g. Resource is
referenced in multiple places with different semantics and different
doc strings.
For now, keep the code out of the external API. The plan is to add
functionality to support Butane docs generation, at which point
internal/doc/generate will move to config/doc.
Update the stabilization checklist to remove manual tweaking of
spec docs.
Quay builds are amd64-only and haven't been especially reliable. Use
GitHub Actions to build both amd64 and arm64 containers for the main
branch and for tags, and push them to Quay. Continue building but not
pushing containers on PR. Requires the QUAY_AUTH repo secret to be set
to a Docker credential.
Ideally we would cross-build the arm64 container by having the Dockerfile
specify FROM --platform=$BUILDPLATFORM for the builder container and set
GOARCH=$TARGETARCH. However, Buildah < 1.24.1 doesn't support --platform
in FROM. Build in emulation for now, and skip arm64 in PRs to speed up CI.
Fixes https://github.com/coreos/ignition/issues/1321.
The container build doesn't care about the selected version of Go in the
host, so there's no point in running it three times. Move the container
build to a separate job, matching Butane CI.
Also switch from docker to podman.
We ship ignition-validate for macOS and Windows, so let's test that in
CI. Ignition contains a lot of Linux-specific code, so it's not practical
to run through the entire ./build and ./test flow. Instead, create a
parallel job that builds ignition-validate and runs only those tests that
are pertinent to it.
