Hi,
Testing Farm release 2024-10.5 was deployed on 2024-12-17 π.
*π Breaking Changes*
The result.xunit field was removed from the API.
Please use result.xunit_url and download the xUnit output instead.
The Testing Farm CLI v0.0.21 has changed parsing of key=value options,
which can break in certain cases.
See the documentation
</testing-farm/docs/root/-/blob/76b2ee79bed589660d86805e35e7fc5d01218bd2/cli.adoc#multiple-kv>
for more details.
Tests defined directly under the discover step using the shell method
are now sorted alphabetically.
If you rely on specific order in which tests are executed, use
explicitly the order attribute as a workaround.
This change will be fixed in the next release.
<#user-content-upgrades>π Upgrades
Testing Farm CLI
</testing-farm/docs/root/-/blob/76b2ee79bed589660d86805e35e7fc5d01218bd2/cli.adoc>
tool updated to v0.0.22
<https://gitlab.com/testing-farm/cli/-/releases/v0.0.22>, please
update your installation.
Artemis <https://gitlab.com/testing-farm/artemis/> was updated to
v0.0.72 <https://gitlab.com/testing-farm/artemis/-/releases/v0.0.72>
on both ranches.
tmt <https://tmt.readthedocs.org> was updated to 1.39
<https://tmt.readthedocs.io/en/stable/releases.html#tmt-1-39>, see
also release notes for 1.36
<https://tmt.readthedocs.io/en/stable/releases.html#tmt-1-36>, 1.37
<https://tmt.readthedocs.io/en/stable/releases.html#tmt-1-36> and 1.38
<https://tmt.readthedocs.io/en/stable/releases.html#tmt-1-38>.
fmf <https://fmf.readthedocs.org> was updated to 1.5
<https://fmf.readthedocs.io/en/stable/releases.html#fmf-1-5-0>.
π― Highlights
Testing Farm onboarding to Red Hat ranch is now self service using Red
Hat Employee SSO.
See the onboarding documentation
</testing-farm/docs/root/-/blob/76b2ee79bed589660d86805e35e7fc5d01218bd2/onboarding.adoc>
for more information.
Preliminary support for Image Mode for RHEL-9.6.0, Fedora-40 and
CentOS-Stream 9 is available.
Read more about the support and possible use cases in our RFD5
</testing-farm/docs/root/-/blob/76b2ee79bed589660d86805e35e7fc5d01218bd2/rfd/rfd5-testing-image-mode.adoc>.
Reservations in Public ranch do not require an ssh proxy anymore and
you can directly connect to the provisioned machines and access all
the ports. (TFT-2678 <https://issues.redhat.com/browse/TFT-2678>)
Support for dedicated (non-spot) AWS instances was added in Red Hat ranch.
This can help with stability of long-running tests and prevents
pre-mature test machine termination by AWS.
See official documentation for details how to enable this for your
requests </testing-farm/docs/root/76b2ee79bed589660d86805e35e7fc5d01218bd2/test-request.adoc#_tags>.
*π Improvements*
The TMT_SSH_* options can now be set by the requests in the
environments[].tmt.environment field.This can help to workaround
unstable network conditions for certain Beaker labs. (TFT-2936
<https://issues.redhat.com/browse/TFT-2936>)
For plans the tmt running log is shown during execution. (TFT-2845
<https://issues.redhat.com/browse/TFT-2845>)
The tmt plans workdir is exposed during tests execution. (TFT-2740
<https://issues.redhat.com/browse/TFT-2740>)
The poweruser role was introduced, making it possible to cancel any
job on Testing Farm.
Improves the experience for teams using automation accounts. (TFT-2706
<https://issues.redhat.com/browse/TFT-2706>)
*π Bugfixes*
Bug causing failed jobs reported as passed in some corner cases was
fixed. (TFT-2847 <https://issues.redhat.com/browse/TFT-2847>)
Fix the long-term problem with archiving, causing occasionally
incomplete logs. (TFT-2750
<https://issues.redhat.com/browse/TFT-2750>)
Fix "Artemis API call failed: Condition 'api_call' failed to pass
within given time" occasional error. (TFT-2734
<https://issues.redhat.com/browse/TFT-2734>)
Fixed a problem when very long secrets would not be hidden in the
logs. (TFT-2698 <https://issues.redhat.com/browse/TFT-2698>)
Fix a problem when the hiding of secrets in logs was currupting yaml
files. (TFT-2487 <https://issues.redhat.com/browse/TFT-2487>)
<#user-content-%EF%B8%8F-packages>π¦οΈ Packages
List of important packages bundled in the worker image.
β― podman run --entrypoint rpm
quay.io/testing-farm/worker-public:2024-10.5 -q fmf tmt
standard-test-roles ansible-core podman beakerlib | sort |
uniqansible-core-2.16.12-1.fc40.noarchbeakerlib-1.31.3-1.fc40.noarchfmf-1.5.0-1.fc40.noarchpodman-5.3.1-1.fc40.x86_64standard-test-roles-4.11-3.fc40.noarchtmt-1.39.0-1.fc40.noarch
π Stats
Testing Farm is on track to surpass 1.33M requests per year
<https://stats.testing-farm.io/d/dpYooDIVk/testing-farm-all-time-stats> \o/.
The average error rate for Testing Farm was approximately 3.10%
<http://metrics.osci.redhat.com/d/NnHWU1dnz/testing-farm?orgId=1&refresh=1m&β¦>.
On the behalf of the Testing Farm Team, /M
Hey folks! This seems like an interesting case that could benefit from
more input, so I figured I'd highlight it for the list.
I got interested in the rpmdeplint failures for the new llvm update -
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e9a5fdd899 - so I
started poking. rpmdeplint reports these failures:
clang18-18.1.7-5.fc42.x86_64 provides /usr/bin/clang++-18 which is also provided by clang-18.1.8-3.fc41.i686
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/clang_rt.crtbegin.o which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/clang_rt.crtend.o which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan-preinit.a which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.a which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
compiler-rt18-18.1.7-3.fc42.x86_64 provides /usr/lib/clang/18/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so which is also provided by compiler-rt-18.1.8-2.fc41.x86_64
... [there are lots more similar compiler-rt ones, cut for space]
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libarcher.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libomp.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
libomp-19.1.0-1.fc42.x86_64 provides /usr/lib64/libompd.so which is also provided by libomp18-18.1.7-3.fc41.x86_64
now in all cases there, the "also provided by" package is the *current*
stable package, and the update contains a newer build of that package
which would not conflict. So there's a clang-19 build, a compiler-rt-19
build, and a libomp18 build in the update, all of which do not
conflict.
So at first I thought "obviously this behavior of rpmdeplint is wrong!
It should not check for conflicts with packages that the update-under-
test would replace". I wrote a PR for that...and it failed tests:
https://github.com/fedora-ci/rpmdeplint/pull/21
the test it failed refers to
https://bugzilla.redhat.com/show_bug.cgi?id=1502458 , which made me
rethink whether this behavior of rpmdeplint is actually *wrong*. That
bug specifically *wanted* rpmdeplint to catch a conflict with a package
that the update would replace. It talks about a real-world case where
vim-minimal and vim-common have some files in common. Now, say you have
vim-minimal-1.0 on your system, but in the updates repo, there's a vim-
2.0 build with different versions of those files. If you tried to
install something that depended on vim-common (but did not cause vim-
minimal to be updated), it would fail, because vim-common-2.0 and vim-
minimal-1.0 from your installed system would conflict. The reporter
argued that rpmdeplint should've caught this and forced vim-common to
add an explicit conflicts with different versions of vim-minimal, which
seems kinda reasonable, honestly.
So that made me rethink whether the issue here is in the update or in
rpmdeplint's behavior. True, if you have an 18 version of clang and
also something that needs clang 18 installed and you just did `dnf
update`, there would be no conflict: dnf would update to clang-19 and
install clang18, and everything would be fine. But if you had an 18
version of clang installed and you tried to do something that, for some
reason, caused clang18 to be pulled in but did *not* cause clang to be
updated (maybe `dnf install clang18-devel` ?), you would hit a
conflict.
So, arguably, the error here is in the package: clang18 should
explicitly conflict with clang < 19, compiler-rt18 should explicitly
conflict with compiler-rt < 19, libomp should explicitly conflict with
libomp18 < 18.1.7-4 . (currently compiler-rt18 has an explicit
conflicts with 'compiler-rt = 18', but that definitely seems wrong; I
don't think that could ever be satisfied.)
What do folks think about this? Do you think the error is in the
package, or in rpmdeplint's analysis? If the former, should we update
the packaging guidelines to specifically cover this case (if they don't
already)? If the latter, how do we change rpmdeplint's behavior,
considering the request in 1502458 ?
Thanks for any thoughts!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net