Testing Farm hotpatch 2024-04.4 with tmt 1.34 has been released!
*Changes*
tmt was updated from 1.33 to 1.34
<https://tmt.readthedocs.io/en/stable/releases.html#tmt-1-34>.
tmt process now accepts more environment variables regarding Reportportal (
infrastructure!632
<https://gitlab.com/testing-farm/infrastructure/-/merge_requests/632>).
*Packages*
List of important packages bundled in the worker image:
❯ podman run --entrypoint rpm quay.io/testing-farm/worker-public:2024-04.4
-q tmt standard-test-roles ansible-core podman beakerlib | sort | uniq
ansible-core-2.16.7-1.fc40.noarch
beakerlib-1.29.3-5.fc40.noarch
podman-5.1.1-1.fc40.x86_64
standard-test-roles-4.11-3.fc40.noarch
tmt-1.34.0-1.fc40.noarch
The next Testing Farm release will be 2024-07.1.
On behalf of the Testing Farm Team
Jan Havlin
Hi,
since we merged the Python 3.13 side tag, the CI on Fedora Rawhide PRs seems
borked.
https://pagure.io/fedora-ci/general/issue/474
Can somebody please take a look? It has been a week.
I can help if the issue is related to Python itself, but this is extremely
impossible for me to debug.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
Hello list!
Is multihost TMT testing supported by Fedora CI? Are there any plans
and/or guides covering it?
I have a component (nodejs-undici) that makes network calls;
I would like to have a separate container running (serving something
similar to https://httpbin.org) that would be available during the test
run and could respond to network requests from the main testing
container.
Thanks in advance for any answers!
--
Jan Staněk
Software Engineer, Red Hat
jstanek(a)redhat.com irc: jstanek
Hello,
The Production Chain Infra Team is planning to do the following services maintainances:
- Upgrade Zuul and Gerrit to the latest versions on the 2024-06-11
- Upgrade the control plane operating systems from CentOS 7 to RHEL 9 on the 2024-06-24.
During these maintainances, the following services are going to be unavailable for a few hours:
- Zuul CI not running jobs for pagure.io or src.fedoraproject.org.
Please let us know if the proposed windows are not good for you.
Regards,
Tristan, on behalf of the Software Factory Operation Team
It looks to me like all tests in Fedora CI are currently failing. I
think this is due to a new release of testing-farm having issues. It
seems like all tests fail somewhere between Jenkins and testing-farm;
Jenkins sends a request to testing-farm, and if you find the log of
that request - e.g.
https://api.dev.testing-farm.io/v0.1/requests/c9516c80-5375-4548-9e52-c8b22…
is one - they all have an error like this:
"Command '['ssh', 'artifacts.dev.testing-farm.io', 'mkdir', '-p', '/archive/c9516c80-5375-4548-9e52-c8b22f838dac']' failed with exit code 1"
I've tried to ping the relevant folks about this, but it may be past
the end of their work day. I don't have the knowledge or access to fix
this myself unfortunately.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
Hi all,
I am looking for feedback and guidance on how to test DNF5 against Fedora
CI.
I'd like to start this discussion before the obsolete switch is turned on
to avoid any disruption.[1]
Currently, the team's plan is to build a side-tag with the DNF-to-DNF5
switch on, and advertise that on the Fedora devel list to gather feedback
and allow users/teams to test their builds/workflows in the side-tag.
Furthermore, I'd like to put together, or update, a list of requirements to
ease the transition from DNF to DNF5.
Any recommendations or ideas that should be followed to test DNF5 in Fedora
CI?
Thanks,
Nicola
[1]: https://pagure.io/fedora-ci/general/issue/416
On Fri, 2024-03-01 at 13:27 -0600, Jason Tibbitts wrote:
> > > > > > Adam Williamson <adamwill(a)fedoraproject.org> writes:
>
> > Honestly, we could really use more automation here, but it's a fairly
> > hard thing to do *reliably* and there just isn't anybody specifically
> > tasked with it so it doesn't happen.
>
> So sure, we could use something but it doesn't have to start out as some
> complex fully automatic system. (Would be nice, but...)
>
> Can we agree that we'd be at least half of the way there if we just had
> a well defined way to:
>
> * Know what package depend on the one you're updating
>
> * Easily bump and chain-build all of that in a side tag
>
> Surely there's a reopquery or fedrq command line that will find at least
> most of what needs to be rebuilt. It doesn't have to be absolutely
> perfect but it can't be that hard to get close. I know there's a
> distinction between build and runtime dependencies and rich/conditional
> dependencies complicate things a bit, but those much smarter than I am
> must have already figured out how to get something that's at least
> somewhat useful.
>
> Once you have the package list, maybe it needs some kind of sorting
> before you can just bump and chain-build things, but I think in many
> cases it doesn't. So, yes, a 100% tool would be really hard but the 80%
> tool really shouldn't be that bad, and almost any tool would really help
> people out.
Yeah, for sure, that's why I'm trying to nibble around the edges by
updating the docs to strongly encourage chain builds, document using
fedpkg chain-build on a side tag, and hopefully get fedpkg chain-build
enhanced so it can create the side tag and the final update
automatically. If we can get that, then I can make the docs explain how
to use it.
ISTR there've been several recent discussions of complex dep chains on
this very list where people have floated candidates for repoquery/fedrq
commands...if there's one we're pretty confident is The Best, we can
definitely plumb that into the docs at least (plumbing it all the way
into fedpkg might be a step too far, though).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net