CI September 2020

ci@lists.fedoraproject.org

7 participants
4 discussions

Fedora 33 pipeline -- is it stuck?
by Jan Pazdziora 22 Oct '20

22 Oct '20

Hello, I've built package for rawhide https://bodhi.fedoraproject.org/updates/FEDORA-2020-f33380047f and the fedora-ci.koji-build.tier0.functional result https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenk… showed up within 20 minutes. I then built the same package for Fedora 33 https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b4c8966de and the WebUI says 1 of 1 required test results missing and looking at the Jenkins pipeline https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenk… no jobs for swid-tools is even there, the last one completed a day ago. Is that expected? -- Jan Pazdziora Product Owner, Platform Security Readiness, Red Hat

2 9

Zuul CI for Fedora - Some news
by Fabien Boucher 10 Sep '20

10 Sep '20

Hello Folks, We've just made it easier to get Zuul jobs running on a Fedora distgit. We are now listening to the Fedora message bus and we are forwarding all Pull Request-related messages to Zuul. This means that, to activate Zuul jobs on distgits's PRs, a package admin (maintainer) no longer needs to configure the webhook url in the project settings. To summarize, to activate Zuul jobs on a distgit, you only need to open a PR on fedora-project-config (see this one as an example [1]). Once that PR is merged, the default jobs will get triggered when a PR is opened/updated/rechecked on that distgit [2]. This service is open to everyone, as long as we have enough compute capacity to run it. So do not hesitate to open PRs. You can see the list of projects that are already running CI jobs with Zuul, here [3]. More details on the wiki page [4]. [1]: https://pagure.io/fedora-project-config/pull-request/107 [2]: https://src.fedoraproject.org/rpms/python-pecan/pull-request/7#comment-55775 [3]: https://fedora.softwarefactory-project.io/zuul/projects [4]: https://fedoraproject.org/wiki/Zuul-based-ci

3 3

Request for Fedora CI team info
by David Cantrell 04 Sep '20

04 Sep '20

Hi, The Fedora Council is working to update the Team Directory in the council-docs project. Part of that is reviewing the teams we have documented and if the information is correct. The Fedora CI Team is currently listed here: https://docs.fedoraproject.org/en-US/engineering/ We are asking for teams to fill out this template so we can have a more consistent listing for team information: https://pagure.io/Fedora-Council/council-docs/blob/master/f/engineering/mod… Can you complete this template and send it to me via email (I am trying to collect and update the engineering team entries)? If you no longer wish to have the team listed in the council-docs, that's fine too. Here is information about what we are trying to accomplish with the Fedora Team Directory: https://docs.fedoraproject.org/en-US/council/procedures/team_directory/ If you have any questions, let me know. Thanks, -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

1 0

Re: Why do gating tests start out 'failed'?
by Adam Williamson 03 Sep '20

03 Sep '20

On Thu, 2020-09-03 at 11:15 +0100, Andrew Price wrote: > Hi, > > I've just enabled gating tests for gfs2-utils and after the new build > finished I got a notification email from bodhi that said: > > "This update's test gating status has been changed to 'failed'." > > On the bodhi update page[0] the "fedora-ci.koji-build.tier0.functional" > test was highlighted red and marked as failed, with no extra information > available. > > After a while, the original 'failed' test turned green and showed > successful, which was puzzling. Why was it marked failed in the first > place? All's well that ends well, but I wasted a bit of time trying to > work out why it had failed when it really hadn't... Because the requirements aren't satisfied. The requirements are that certain specific tests pass. When Bodhi asks Greenwave what the status for a given update is, if there are passes for all of those tests, it says "passed". If not, it says "failed". That's all the subtlety there is. :) I suggested a while back that we should be able to define requirements in Greenwave as "if a result for this test exists, it must be pass" (but if no result exists, that's OK too). It hasn't been done, though, and some folks at least didn't think it was a good idea due to the possibility of allowing broken things through due to test names changing, issues in the test systems, etc. It also produces an obvious loophole that everything passes CI right after it's submitted, unless you start getting a bit hacky with minimum times to wait for results to appear and stuff, which starts to get complicated and possibly fragile. We could improve things somewhat here if we had an equivalent of ResultsDB (the source of truth for test results for this whole system) for test *execution*, but we don't. Any test system that wants into The System has to submit results to ResultsDB, but we don't have an equivalent test *execution* database that everything has to submit to. We do have a standard for text execution *messaging* - https://pagure.io/fedora-ci/messages - but not all test systems are entirely compliant with it, and using the info would require work in Greenwave and Bodhi and maybe elsewhere. I think Greenwave may provide some extended info here that Bodhi could use to be a bit more detailed (I *think* the 'extended' Greenwave result includes info on which tests are *failed* and which tests are *missing*); if it doesn't it could, and then Bodhi could actually draw a visual distinction between "there are failed tests" and "there are no failed tests but we don't have passes for all required tests yet". That might be an improvement. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 1

2024

2023

2022

2021

2020

2019

2018

2017

CI September 2020