14:35:52 <jbair> #startmeeting Fedora CI SIG
14:35:52 <zodbot> Meeting started Wed Oct 21 14:35:52 2020 UTC.
14:35:52 <zodbot> This meeting is logged and archived in a public location.
14:35:52 <zodbot> The chair is jbair. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:35:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:35:52 <zodbot> The meeting name has been set to 'fedora_ci_sig'
14:35:52 <jbair> .hello jimbair
14:35:53 <zodbot> jbair: jimbair 'Jim Bair' <jbair@redhat.com>
14:35:59 <msrb> jbair, afaik, no user visible changes; just reshuffling things around a bit
14:36:04 <msrb> .hello msrb
14:36:04 <zodbot> msrb: msrb 'Michal Srb' <msrb@redhat.com>
14:40:41 <jbair> lookin' a bit sparse today :) Might need to do some work between now and next time to ensure we've got an agenda; we had a moving one for awhile :)
14:41:02 <jbair> Though primarily I've seen msrb's commits into our repos (and new repo creation in the fedora-ci org)
14:41:54 <msrb> I don't remember creating any new repos :)
14:42:09 <jbair> I'd have to check my gmail but over the last 2-4 weeks I see new repos created
14:42:17 <jbair> could be you or someone else :) I mostly see PRs from you :D
14:43:07 <msrb> oh, ok, if we are talking 2-4 weeks, then it is possible that it was me :)
14:43:12 <msrb> but not last week :P
14:44:19 <jbair> yeah, these meetings are every 2 weeks, so between those :) I also get github notifications to my personal gmail so I see those when I wake up in the morning lol
14:44:24 <jbair> as well as over the weekends :)
14:45:44 <msrb> so the reason for those pull requests is often that Jenkins creates a production-like pipeline deployment for you, where you can test changes easily
14:46:15 <msrb> often those PRs are closed without merging because the test environment is no longer needed
14:47:02 <jbair> ah, good to know
14:47:07 <bookwar> msrb: i have one question for you
14:47:13 <msrb> it would be great to be able to run stuff locally, but that's not always easy in Jenkins world
14:47:16 <msrb> bookwar, shoot
14:47:38 <bookwar> there is an issue with glibc in rawhide currently, and i was wondering if our tests could have prevented that
14:48:01 <bookwar> so i checked the results and i am not sure how to read them
14:48:10 <msrb> let me check
14:48:24 <bookwar> https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpmdeplint-pipeline/job/master/8618/console
14:48:51 <bookwar> this link is better https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpmdeplint-pipeline/job/master/8618/testReport/(root)/tests/_check_conflicts_x86_64/
14:49:07 <bookwar> so it is a failed test but with empty output
14:49:37 <bookwar> maybe we can discuss it later
14:49:58 <msrb> bookwar, "Error: "/check-conflicts-x86_64" test failed to run. This is likely an infrastructure issue."
14:50:28 <msrb> it took 4.5 hours to run the test. so I guess it was timeout-killed at the end
14:50:44 <bookwar> for other arches the output shows the conflicts
14:50:55 <bookwar> but for x86 it just fails
14:51:14 <bookwar> indeed, it is glibc, may be huge
14:53:35 <msrb> yeah, it was timeout in tmt: http://artifacts.dev.testing-farm.io/fc508e75-5d98-4307-aacf-78d83d79c338/work-rpmdeplinteUITu8/rpmdeplint/execute/
14:53:43 <msrb> results.yaml has the info
14:54:12 <msrb> such problem is not yet properly communicated back to user
14:56:02 <msrb> also, it's weird that the overall outcome is fail and not error
14:56:39 <msrb> that's something we will need to sort out with testing farm
14:56:51 <jbair> yeah, a test taking too long is an error for sure
14:56:58 <jbair> (in my brain)
14:59:09 * mvadkert reading
14:59:19 <msrb> that rpmdeplint file conflict test is slow
14:59:53 <msrb> for packages with thousands of packages, it can take 1+ hour, for a single architecture
15:00:35 <mvadkert> msrb: http://artifacts.dev.testing-farm.io/fc508e75-5d98-4307-aacf-78d83d79c338/results.xml
15:00:39 <mvadkert> msrb: it run on testing farm
15:00:43 <mvadkert> and seems failed
15:00:53 <mvadkert> <testcase name="/check-conflicts-aarch64" result="failed">
15:01:04 <mvadkert> http://artifacts.dev.testing-farm.io/fc508e75-5d98-4307-aacf-78d83d79c338/work-rpmdeplinteUITu8/rpmdeplint/execute/logs/check-conflicts-aarch64/out.log
15:01:10 <mvadkert> bookwar: is that it?
15:01:12 <msrb> mvadkert, yeah, I think confusing part is http://artifacts.dev.testing-farm.io/fc508e75-5d98-4307-aacf-78d83d79c338/work-rpmdeplinteUITu8/rpmdeplint/execute/
15:01:16 <msrb> mvadkert, results.yaml
15:01:26 <msrb> mvadkert, there are timeout errors from tmt (expected)
15:01:37 <mvadkert> msrb: I see
15:01:39 <msrb> mvadkert, but overall result from TF was reported as failed
15:01:53 <mvadkert> msrb: right,but we would like error :)
15:01:54 <msrb> mvadkert, I'd probably expect error as an overall outcome
15:01:58 <mvadkert> I have almost the support tghere
15:01:58 <msrb> mvadkert, yep :)
15:02:02 <mvadkert> msrb: agreed
15:02:10 <mvadkert> you need to start expose
15:02:27 <msrb> mvadkert, I will open an issue in fedora-ci/general for this
15:02:48 <mvadkert> that option I added
15:03:03 <mvadkert> msrb: I guess I can roll that out fairtly quickly next week, other prios this week
15:03:28 <mvadkert> msrb: true it would catch the problem on our side, but seems 4.5 hours is not enough for sych large packages :(
15:03:36 <msrb> mvadkert, oh, is it supported already? that new option? I know about the API change proposal, but I didn't know that it is already implemented :)
15:04:04 <mvadkert> interestingly
15:04:21 <mvadkert> only on x86_64 it run for 1.5 hours
15:04:27 <mvadkert> 01:30:00 /check-conflicts-x86_64 (timeout)[0m
15:04:34 <mvadkert> other archs worked
15:04:35 <mvadkert> 01:19:51 /check-conflicts-aarch64[0m
15:04:39 <mvadkert> 11 minutes
15:04:46 <mvadkert> msrb: i would raise it for now
15:04:56 <mvadkert> msrb: it is not there :) next week
15:04:58 <mvadkert> msrb: sorry
15:05:04 <mvadkert> msrb: I have all the patchs
15:05:08 <mvadkert> just will need to deploy
15:06:09 <msrb> well, that's weird
15:06:33 <msrb> 11 minutes vs 90 minutes (90 is the hard limit that we set in tmt iirc)
15:06:59 <msrb> that stinks... like some kind of slow network problem
15:40:07 <jbair> #endmeeting