fedora_ci_sig
LOGS
15:30:20 <jbair> #startmeeting Fedora CI SIG
15:30:20 <zodbot> Meeting started Wed Jan 27 15:30:20 2021 UTC.
15:30:20 <zodbot> This meeting is logged and archived in a public location.
15:30:20 <zodbot> The chair is jbair. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:30:20 <zodbot> The meeting name has been set to 'fedora_ci_sig'
15:30:20 <jbair> .hello jimbair
15:30:21 <zodbot> jbair: jimbair 'Jim Bair' <jbair@redhat.com>
15:33:19 <msrb> .hello msrb
15:33:20 <zodbot> msrb: msrb 'Michal Srb' <msrb@redhat.com>
15:34:42 <jbair> I do wonder if we need to move this to a different time; possibly we're conflicting with something :)
15:34:46 <jbair> We used to have far more attendance
15:34:58 <bgoncalv> .hello2
15:35:01 <zodbot> bgoncalv: bgoncalv 'Bruno Goncalves' <bgoncalv@redhat.com>
15:35:42 <bgoncalv> any specific topic to discuss? Maybe people just forgot about the meeting, we can try to ping them :)
15:36:09 <jbair> No specific topics today
15:36:15 <jbair> I am wondering if we need to find a better time for it?
15:36:24 <jbair> Maybe another Fedora meeting is conflicting
15:36:27 <jbair> like FESCo or something
15:37:22 <jbair> I know that's this morning (my time) but not sure exactly when
15:39:26 <jbair> I'll send a note after we wrap here about it to ci@
15:39:44 <jbair> any topics you two wanted to discuss? I know we're still working on the new jenkins; are both 1 and 2 working? Or are we mostly only configured on 1?
15:40:33 <bgoncalv> I haven't touched Fedora CI for a while now, but yes I assume pipelines are working
15:40:49 <bgoncalv> pipeliens are running on jenkins-1, monitor bots on jenkins-2
15:41:23 <jbair> I haven't heard much, which is usually good news :)
15:41:51 <bgoncalv> jbair: since last meeting only infra issue are posted to this channel
15:42:22 <jbair> I didn't make any changes so I would guess someone else did?
15:42:34 <bgoncalv> I did, this was just FYI :)
15:42:41 <jbair> ah, well thanks :)
15:42:50 <jbair> It seems far less noisy, and I appreciate it
15:43:04 <msrb> yep, I asked Bruno to silence the test failure notifications ;)
15:43:13 <jbair> msrb: ty :)
15:47:00 <msrb> one thing worth sharing:
15:48:25 <jbair> what's that?
15:48:31 <msrb> people asked about gating on scratch-builds of dependent components; like pass gating if scratch-builds of dependent components were successful
15:48:44 <msrb> sounds like Koschei
15:49:18 <msrb> however, they only wanted a specific list of components (kernel right now, when glibc changes)
15:49:37 <jbair> so like kernel gating against scratch builds of glibc?
15:49:47 <msrb> so I tried to prototype it today: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6c71425dab
15:50:17 <msrb> jbair, the other way around, glibc gating against kernel scratch-builds
15:51:14 <bgoncalv> I think greenwave doesn't support results for scratch builds...
15:51:29 <bgoncalv> even if resultsdb gets update to save it
15:51:37 <msrb> bgoncalv, kernel scratch build is reported as glibc test result
15:51:47 <bgoncalv> ahhh
15:51:55 <msrb> bgoncalv, with "scenario: kernel"
15:52:12 <msrb> but scenarios doesn't seem to be supported in resultsdb-updater yet
15:53:01 <msrb> so people should be able to add "!PassingTestCaseRule {test_case_name: fedora-ci.koji-build.build.static-analysys, scenario: kernel} to their gating.yaml
15:53:14 <msrb> and of course not only kernel, but any other component name as well
15:53:31 <msrb> but yeah, it doesn't work properly end-to-end yet
15:53:42 <bgoncalv> seems some sort of reverse dependency, but the revdep pipeline would create this scratch build
15:53:49 <msrb> yep
15:53:50 <msrb> exactly
15:53:54 <msrb> same thing basically
15:54:11 <bgoncalv> the new kernel build should use the new glibc
15:54:32 <bgoncalv> but the glibc will not be in buildroot, as didn't pass gating, right?
15:54:46 <msrb> yeah, I add new glibc to a side-tag and then scratch-build kernel in it
15:55:02 <msrb> that's what I am doing right now
15:55:50 <msrb> one big missing piece is configuration: how will people tell us which components to scratch-build
15:56:03 <bgoncalv> what about instead of using scenario, we use different testcase name?
15:56:07 <msrb> but we will need to figure out the same for regular revdeps pipeline as well
15:56:28 <bgoncalv> test_case_name: fedora-ci.koji-build.build.revdep-glibc-kernel ?
15:57:07 <bgoncalv> we could use same syntax used for explicit define revdep tests as used internally
15:57:15 <bgoncalv> on ci.fmf
15:57:55 <msrb> bgoncalv, yeah, unique test case name would work as well
15:58:14 <bgoncalv> should help us to waive and rerun only what we want
15:58:14 <msrb> I just thought that scenarios are a bit cleaner solution
15:58:50 <msrb> scenario is basically additional context for the test result
15:59:17 <bgoncalv> not sure how this work in the infra
15:59:18 <msrb> so "the same scratch-build test, but with package xyz"
15:59:27 <bgoncalv> like greenwave, bodhi interface... :)
15:59:39 <msrb> bgoncalv, bodhi is already able to visualize it
15:59:47 <bgoncalv> cool
16:01:15 <msrb> like here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b71b8a85c8
16:01:39 <msrb> those "x86_64 workstation" strings (should be) scenarios
16:01:57 <msrb> they *should* be waivable independently
16:02:13 <jbair> I can put this in my post-meeting email for discussion to see if people have any thoughts about it (a thing I plan on doing to try and boost attendance)
16:02:19 <msrb> and since all those are separate messages, people will be able to click and rerun only what they want
16:02:39 <msrb> jbair, go for it ;)
16:03:28 <bgoncalv> okay, nothing more to add :)
16:03:28 <jbair> I hopped into a 10AM meeting so I'll send it after that; give it a read and reply if I get any details wrong :)
16:03:54 <msrb> ;)
16:26:30 <jbair> okay thanks guys :)
16:26:36 <jbair> #endmeeting