Rocky Linux Testrarc Shows Which Environments Passed Release Tests

A passing test on an x86_64 KVM guest tells you something useful about Rocky Linux. It tells you less about a bare-metal aarch64 host. With Testrarc, announced on November 4, the project gives readers a way to see the environment behind a test result before they use it to make an upgrade decision.

Read the environment before the status

Rocky Linux says Testrarc replaces its reliance on Mattermost Playbooks as the main way to track release validation. The new dashboard organizes tests by release stage, including beta and release candidates. It records who ran the test, whether it passed, failed or was partial, and where it ran. The project lists bare metal, KVM, containers, VMs and cloud among the environment types. The dashboard is public. A Rocky account is needed to submit a result.

The project has made beta testing results for Rocky Linux 10.3 and 9.9 available to explore. Start on the Testrarc dashboard with the release you intend to evaluate. Check the candidate first, then the architecture and environment for the test that matters to you. For example, if you maintain an x86_64 cloud image and a set of ARM machines in a lab, look up the two cases separately. Write down which ones match and which ones still need a run of your own.

Use the report to choose your staging tests

Take a host that depends on a particular storage controller. A clean installation in a virtual machine is a useful check on the installer. To decide whether to upgrade that host, use a staging machine with the controller and the boot mode you actually rely on. Check that it sees the expected disks, boots after the update and can reach the services you need. Keep a recovery path available before starting. A dashboard entry can help you decide what to test first and where to spend less time.

LinuxHospital’s look at Fedora’s remaining startup reports offers a similar example of why test context matters. With Rocky, check a partial result for the specific condition that remains open. Where the dashboard has no matching result, treat that case as open in your own checklist.

People with a spare machine can also contribute. Rocky identifies tests suitable for volunteers using the community_testable tag. Read the test criteria, choose a case your setup can reproduce, and record the candidate, architecture and environment with the result. Someone reading it later can then tell whether your test resembles the system they need to upgrade.