| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: web: add OpenAPI documentation https://review.openstack.org/535541 | 01:17 |
|---|---|---|
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: config: add playbooks to job.toDict() https://review.openstack.org/621343 | 01:22 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: config: add tenant.toDict() method and REST endpoint https://review.openstack.org/621344 | 01:23 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: config: add tenant.toDict() method and REST endpoint https://review.openstack.org/621344 | 01:31 |
| *** rfolco has joined #zuul | 01:31 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: scheduler: add job's parent name to the rpc job_list method https://review.openstack.org/573473 | 01:43 |
| *** bhavikdbavishi has joined #zuul | 02:28 | |
| *** bhavikdbavishi has quit IRC | 02:47 | |
| *** rfolco has quit IRC | 02:59 | |
| *** bhavikdbavishi has joined #zuul | 03:35 | |
| *** bhavikdbavishi1 has joined #zuul | 03:38 | |
| *** bhavikdbavishi has quit IRC | 03:39 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:39 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: config: add playbooks to job.toDict() https://review.openstack.org/621343 | 03:40 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: config: add tenant.toDict() method and REST endpoint https://review.openstack.org/621344 | 03:40 |
| *** swest has quit IRC | 06:30 | |
| *** swest has joined #zuul | 06:32 | |
| *** quiquell|off is now known as quiquell | 07:06 | |
| *** bjackman has joined #zuul | 07:08 | |
| *** arxcruz|next_yr is now known as arxcruz | 07:47 | |
| *** quiquell is now known as quiquell|brb | 08:04 | |
| *** quiquell|brb is now known as quiquell | 08:52 | |
| *** hashar has joined #zuul | 09:14 | |
| openstackgerrit | Simon Westphahl proposed openstack-infra/zuul master: Fix skipped job counted as failed https://review.openstack.org/625910 | 09:50 |
| quiquell | Happy new year ! | 09:58 |
| quiquell | Have a new year question regarding nodepool | 09:58 |
| quiquell | It's possible to use multipleo nodepool-launchers towards same openstack tenant/project ? | 09:59 |
| *** bhavikdbavishi has quit IRC | 10:09 | |
| *** quiquell is now known as quiquell|brb | 11:11 | |
| *** sshnaidm is now known as sshnaidm|afk | 11:48 | |
| Shrews | quiquell|brb: you may have multiple launchers, but they should not share any providers. we currently do not have the coordination between launchers to be able to do that | 12:11 |
| *** quiquell|brb is now known as quiquell | 12:11 | |
| quiquell | Shrews: ack, thanks | 12:12 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift resource provider https://review.openstack.org/570667 | 12:18 |
| openstackgerrit | Sorin Sbarnea proposed openstack-infra/zuul-jobs master: Remove world writable umask from /src folder https://review.openstack.org/625576 | 12:26 |
| *** rlandy has joined #zuul | 12:39 | |
| *** rlandy is now known as rlandy|rover | 12:42 | |
| *** rfolco has joined #zuul | 12:43 | |
| *** sshnaidm|afk is now known as sshnaidm | 12:43 | |
| *** quiquell is now known as quiquell|lunch | 12:48 | |
| *** bjackman has quit IRC | 12:58 | |
| *** quiquell|lunch is now known as quiquell | 13:48 | |
| *** nhicher has joined #zuul | 14:04 | |
| *** hashar has quit IRC | 14:12 | |
| *** hashar has joined #zuul | 14:12 | |
| *** dkehn has joined #zuul | 14:47 | |
| *** bhavikdbavishi has joined #zuul | 14:55 | |
| *** bhavikdbavishi has quit IRC | 15:10 | |
| *** bhavikdbavishi has joined #zuul | 15:10 | |
| pabelanger | morning! | 15:15 |
| * SpamapS watches the working world slowly thaw and begin to re-animate after 2 weeks of winter freeze | 15:16 | |
| pabelanger | Ha, wish we had winter freeze here. On average been 8C over the break | 15:17 |
| pabelanger | no snow here this year | 15:17 |
| *** quiquell is now known as quiquell|off | 15:17 | |
| *** rfolco is now known as rfolco|lunch | 15:18 | |
| *** bhavikdbavishi has quit IRC | 15:19 | |
| Shrews | anyone here knowledgable in wheel building? | 15:21 |
| SpamapS | Shrews: I've fashioned a wheel or two, but nothing deep. What's up? Maybe just need to talk to teddy? | 15:36 |
| Shrews | for some reason, pbrx builds are failing when installing the latest release of netifaces (see http://logs.openstack.org/70/608670/2/gate/pbrx-build-container-images/c157205/job-output.txt.gz#_2019-01-02_14_45_42_208267) during the wheel build | 15:37 |
| Shrews | i can build the package fine locally with 'python setup.py install' | 15:38 |
| Shrews | and the LICENSE file is indeed there | 15:38 |
| Shrews | so thought maybe there was something special with what the wheel build expects/does | 15:38 |
| Shrews | mordred: fyi ^^ | 15:39 |
| *** hashar has quit IRC | 15:39 | |
| pabelanger | Shrews: could be related to https://github.com/al45tair/netifaces/commit/0bf4a1222a91c9ad9b9c729ba2bc97456da5b559 ? there is also a new release only 5 hours old today | 15:39 |
| *** hashar has joined #zuul | 15:40 | |
| Shrews | pabelanger: that change was included in 0.10.7 back in may (https://github.com/al45tair/netifaces/commit/4fa0e314ae1fc292a2b8afd37f31e9323bccbfea) | 15:41 |
| pabelanger | Shrews: right, seems 0.10.8 was first release to pick it up | 15:42 |
| pabelanger | I don't think you can include a file like that with metadata | 15:42 |
| pabelanger | no, I am wrong | 15:42 |
| pabelanger | https://setuptools.readthedocs.io/en/latest/setuptools.html#metadata | 15:42 |
| Shrews | oh nice, so the release in pypi for 0.10.7 does not match the actual changelog changes | 15:44 |
| Shrews | at any rate, not sure what the problem is or where the fault lies | 15:47 |
| pabelanger | Shrews: the tarball is missing a LICENSE file | 15:48 |
| pabelanger | so I think this is a release problem | 15:48 |
| Shrews | pabelanger: that change is using the metadata key 'license_file' but the setuptools doc references 'license' as the key. could that be the issue? | 15:49 |
| pabelanger | Shrews: yah, i think that is also wrong | 15:49 |
| pabelanger | I can test shortly | 15:50 |
| pabelanger | but first issue will be getting LICENSE file added into tarball i think | 15:50 |
| pabelanger | but I need to #dadops first for a bit | 15:50 |
| Shrews | does that metadata control adding it to the tarball? | 15:50 |
| corvus | mordred, SpamapS: i did write down thoughts on logging: http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-July/000501.html | 15:51 |
| SpamapS | corvus: mmm I remember these thoughts. I like them. :) | 15:52 |
| *** rfolco|lunch is now known as rfolco | 15:55 | |
| Shrews | pabelanger: oh, seems license_file is correct for wheel (https://wheel.readthedocs.io/en/stable/user_guide.html#including-license-files-in-the-generated-wheel-file) | 15:59 |
| SpamapS | Python packaging, where 10 years of fixes and improvements still confuse basically everyone. :-P | 16:02 |
| Shrews | pabelanger: LICENSE does not exist for the previous versions #confused | 16:04 |
| Shrews | SpamapS: it really is a mess, isn't it? | 16:04 |
| mordred | ++ | 16:04 |
| corvus | mordred, SpamapS, tobiash, tristanC: regarding https://review.openstack.org/622010 -- that still looks very bad for me at 1280x1024; how can we fix that? | 16:06 |
| corvus | that's some css magic there and i don't understand where those values come from or what they mean | 16:07 |
| tobiash | corvus: it's the number of columns in bootstraps grid system for different screen sizes: https://getbootstrap.com/docs/4.0/layout/grid/#grid-options | 16:08 |
| tobiash | if it still looks bad for 1280x1024 we probably need to remove 'col-lg-3' and live with max three columns | 16:09 |
| corvus | tobiash: ah, thanks for that link | 16:10 |
| corvus | i'm seeing 4 columns at 1280... which is confusing | 16:10 |
| tobiash | 1280 probably already fits into the large category | 16:11 |
| tobiash | we could try changing col-lg-3 to col-xl-3 to use 4 columns at larger screens | 16:12 |
| SpamapS | I don't mind the 4 columns. | 16:15 |
| corvus | maybe it's too early -- i feel like i'm missing something -- why are we changing the 'lg' class for smaller screen sizes? | 16:16 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Switch back to three columns for mid sized screens https://review.openstack.org/627997 | 16:16 |
| tobiash | corvus: I think this should do it ^ | 16:16 |
| corvus | SpamapS: i don't mind having as many colums as we can fit, however, on my screen we can't fit 4 in that size. the progress bars overlap the change numbers, and the project names take up 3 lines | 16:17 |
| SpamapS | oh weird | 16:17 |
| corvus | i posted a screenshot when i first reviewed it. it seems to have expired now, but mordred posted a similar one | 16:17 |
| SpamapS | I'm at 2560x1440 scaled 200% ... that doesn't happen. | 16:18 |
| corvus | https://screenshots.firefox.com/ocT0BNtkqBHWdfvg/zuul.openstack.org# | 16:19 |
| tobiash | corvus: yes, that really looks ugly | 16:19 |
| corvus | tobiash: i still feel like im missing something about the bootstrap -- that reads to me as "use 6 colums for small screens and 3 columns for extra large screens" why is that backwards? | 16:21 |
| tobiash | oops, that misses col-md-4 | 16:22 |
| mordred | corvus: I think it's 'make the column 6 grid units wide' | 16:22 |
| corvus | mordred: oh thank you :) | 16:22 |
| mordred | with a max 12 grid units available | 16:22 |
| corvus | what an aweful coincidence | 16:22 |
| mordred | corvus: it took me most of this conversation to figure that out | 16:22 |
| tobiash | corvus: so the classes are: col-sm-6 col-md-4 col-xl-3 | 16:22 |
| tobiash | lg is missing so md takes precedence | 16:23 |
| tobiash | so that reads like take 6/12 units for small screens, 4/12 units for medium to large screens and 3/12 units for extra large screens | 16:23 |
| corvus | got it! thanks :) | 16:24 |
| * corvus clicks on status icon for http://zuul.openstack.org/status/change/627997,1 | 16:24 | |
| mordred | \o/ | 16:25 |
| tobiash | corvus, mordred: looks like we currently use bootstrap 3, but the xl class for extra large screens were introduces with bootstrap 4 | 16:31 |
| mordred | ah | 16:31 |
| tobiash | so it ignores theat and shows three columns on my 4k screen | 16:31 |
| tobiash | but 627997 should still fix it for 1280 and probably work when we switch to bootstrap 4 | 16:32 |
| corvus | so we'll be at 3 columns x>720 until we upgrade to bs4, then we'll have 3 columns for 720<x<1140 and 4 columns x>1140? | 16:34 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Switch back to three columns for mid sized screens https://review.openstack.org/627997 | 16:37 |
| tobiash | corvus: actually we don't really know for sure how it will look like so we should just remove the xl class for now ^ | 16:37 |
| tobiash | after an upgrade we can try to add it again | 16:38 |
| tobiash | and it looks like react-bootstrap doesn't support bootstrap 4 yet: https://react-bootstrap.github.io/ | 16:39 |
| dmsimard | I was trying to understand why a job I'm working on did not run and noticed this: zuul.Pipeline.openstack.check: Completed node request <NodeRequest None <NodeSet []>> for job noop of item <QueueItem 0x7fdc9cfd3f98 for <Change 0x7fdc3ce6d8d0 openstack/ara-web 625666,9> in check> with nodes <NodeSet []> | 16:39 |
| dmsimard | Should there really be a node request for the noop job ? | 16:39 |
| dmsimard | I guess it's noop and doesn't really request one but /shrug | 16:40 |
| tobiash | dmsimard: zuul creates an empty node request (which doesn't land in zk) | 16:40 |
| mordred | tobiash: ++ - sounds like the sequence there should be react-bootstrap adding support for v4, us upgrading to bs4, then adding the xl column | 16:40 |
| dmsimard | There's even metrics attached to the noop job heh: zuul.nodepool: Nodeset <NodeSet []> with 0 nodes was in use for 3.170967102050781e-05 seconds for build <Build 691752f3a675457e8162b00561aeea01 of noop voting:True on <Worker Unknown>> for project openstack/ara-web | 16:40 |
| dmsimard | "3.170967102050781e-05" that's almost pi or something | 16:41 |
| mordred | dmsimard: :) | 16:41 |
| tobiash | dmsimard: zuul self-fulfills empty node requests | 16:43 |
| dmsimard | tobiash: makes sense | 16:43 |
| dmsimard | my brain is still frozen from the holidays :p | 16:43 |
| dmsimard | Oh wow, there was a bunch of things merged to zuul-web during the holidays -- thanks everyone involved in that <3 | 16:45 |
| SpamapS | corvus: ah ok actually yeah mine looks a bit like yours, just a teensy bit more space around stuff | 16:48 |
| SpamapS | how far are we from having buildset in the API? I'm really struggling to have a meaningful github success status. :-/ | 16:49 |
| corvus | SpamapS: yeah, it's borderline. if you have a short project name and not too many patchsets, it's almost ok. | 16:49 |
| corvus | SpamapS: i don't see an outstanding change for it, but at this point i don't think there would be any blockers | 16:50 |
| dmsimard | What is the default sort order for http://zuul.openstack.org/nodes ? It feels... random and it makes it less useful ? I'd expect it to be sorted by ID but it's not. | 16:53 |
| corvus | dmsimard: i think it may be unsorted. | 16:54 |
| corvus | dmsimard: https://review.openstack.org/553998 added it and shows the code involved if you want to make a patch :) | 16:56 |
| dmsimard | corvus: would the sorting be done by the API or client side ? | 16:56 |
| dmsimard | unless mistaken, the react data table allows for client side sorting -- a bit like you can click the table headers in the ara web interface | 16:57 |
| corvus | dmsimard: i think we could have the api return them in id-sorted order if you wanted; anything more is probably better done client-side. | 16:58 |
| corvus | (since there's no pagination, there's not much of a reason for the api to support other sort options) | 16:59 |
| dmsimard | ++ | 16:59 |
| *** hashar has quit IRC | 17:27 | |
| *** hashar has joined #zuul | 17:27 | |
| tobiash | mordred: looks like zuul container builds are broken: http://logs.openstack.org/70/608670/2/gate/pbrx-build-container-images/c157205/job-output.txt.gz#_2019-01-02_14_46_02_408220 | 17:45 |
| tobiash | and http://logs.openstack.org/70/608670/2/gate/zuul-quick-start/69be362/job-output.txt.gz#_2019-01-02_14_46_46_933231 | 17:46 |
| tobiash | mordred: that happens during installing netifaces which is pulled in by openstacksdk | 17:46 |
| mordred | tobiash: yeah - I think Shrews is looking at that | 17:46 |
| tobiash | ah ok | 17:46 |
| mordred | something seems to be broken with the latest netifaces release | 17:46 |
| tobiash | looks like it got an update and fails to install on alpine now | 17:47 |
| mordred | which doesn't allow us to build wheels from it | 17:47 |
| mordred | yeah | 17:47 |
| mordred | easiest fix might just be pinning netifaces back a version until it's sorted | 17:47 |
| clarkb | or exclude the broken version (and hope next version fixes) | 17:47 |
| tobiash | oops, didn't read the whole backlog | 17:48 |
| *** kmalloc has joined #zuul | 17:50 | |
| Shrews | mordred: tobiash: well, i've yet to determine what about this version of netifaces is broken since previous version did not include the LICENSE file either. hoping pabelanger's wheel experience can help us | 17:51 |
| clarkb | Shrews: https://github.com/al45tair/netifaces/commit/0bf4a1222a91c9ad9b9c729ba2bc97456da5b559 the lastest version has that in it | 17:54 |
| clarkb | the previous one does not | 17:54 |
| Shrews | clarkb: yes, we discussed that earlier | 17:54 |
| clarkb | that is what is broken in this version then? | 17:55 |
| clarkb | previous versiosn didn't try to include a license file so it wouldn't execute the broken code path | 17:55 |
| tobiash | Shrews: installing it in a local alpine container works for me | 17:56 |
| Shrews | tobiash: yes, i tried that earlier too | 17:56 |
| tobiash | weird | 17:57 |
| Shrews | seems specific to using wheels | 17:57 |
| clarkb | I think the issue is that setuptools includes files in the python module but not things above that | 17:57 |
| clarkb | so LICENSE doesn't get included in the resulting sdist as is | 17:57 |
| clarkb | then when you try to build a package from that it is missing the necessary file | 17:58 |
| clarkb | if you build from the source dir this isn't an issue | 17:58 |
| *** kmalloc has quit IRC | 17:58 | |
| mrhillsman | does zuul.openstack.org have some extra changes upstream zuul does not have? i ask because i am running the latest zuul and the navigation menu is different | 17:58 |
| Shrews | https://github.com/al45tair/netifaces/issues/30 | 18:01 |
| *** sshnaidm is now known as sshnaidm|afk | 18:05 | |
| mrhillsman | for comparison - http://ci-status.openops.io/t/openops/status | 18:11 |
| clarkb | mrhillsman: I think it depends on your scheduler being up to date as that requires more data in the api/db | 18:12 |
| clarkb | openstack isn't running any special unmerged code | 18:13 |
| mrhillsman | ok thx | 18:13 |
| mrhillsman | will review my end | 18:13 |
| mrhillsman | s/review/fix | 18:13 |
| *** hashar has quit IRC | 18:15 | |
| *** panda is now known as panda|off | 18:15 | |
| *** hashar has joined #zuul | 18:15 | |
| *** hashar has quit IRC | 18:24 | |
| *** hashar has joined #zuul | 18:24 | |
| *** hashar has quit IRC | 18:33 | |
| *** hashar has joined #zuul | 18:33 | |
| *** hashar has quit IRC | 18:37 | |
| pabelanger | Shrews: clarkb: if we switch from license_file to license does that make setuptools happy? | 18:37 |
| pabelanger | I'm going to test that locally now | 18:37 |
| *** hashar has joined #zuul | 18:37 | |
| pabelanger | clarkb: Shrews: https://github.com/al45tair/netifaces/pull/31 was the fix for me | 18:48 |
| pabelanger | I am not familiar enough with packaging to understand why it wasn't auto added | 18:48 |
| clarkb | pabelanger: because it isn't part of the python package dir | 18:49 |
| pabelanger | clarkb: how does it work with PBR? do we generate the MANIFEST.in file automatically at run time? | 18:50 |
| *** hashar has quit IRC | 18:52 | |
| clarkb | pbr adds everythin in git by default | 18:53 |
| pabelanger | PR merged, guess we wait for new upload to pypi | 18:58 |
| *** tobiash has quit IRC | 19:02 | |
| dmsimard | Is there a way to trigger a autohold for a specific provider ? | 19:05 |
| dmsimard | or set a autohold, rather | 19:05 |
| *** tobiash has joined #zuul | 19:06 | |
| pabelanger | not unless you setup the label only for that provider | 19:06 |
| dmsimard | hmm, it'd be nice to have to troubleshoot intermittent failures on a specific provider :) | 19:07 |
| pabelanger | clarkb: Shrews: netifaces 0.10.9 released, doing a recheck now | 19:16 |
| pabelanger | okay, seems to be working now: http://logs.openstack.org/70/608670/2/check/pbrx-build-container-images/a8b288f/ | 19:25 |
| dmsimard | Could nodes from a given nodeset be on different providers ? "provider" appears to be a node property, not a nodeset property | 19:34 |
| dmsimard | http://git.zuul-ci.org/cgit/zuul/tree/zuul/model.py#n536 | 19:35 |
| mordred | pabelanger: \o/ | 19:36 |
| mordred | dmsimard: nodes in a nodeset should all come from the same provider | 19:36 |
| SpamapS | but I think what pabelanger wants to do is specifically send a test job to a provider | 19:37 |
| SpamapS | so like "give me 2 nodes, *from rax-ord*" | 19:37 |
| dmsimard | mordred: I'm looking at the possibility of specifying a provider in a autohold request but it doesn't seem readily available unless I iterate through something like nodeset.getNodes() and then inspect each individual node provider | 19:37 |
| SpamapS | oh, not pabelanger , dmsimard | 19:37 |
| SpamapS | ;) | 19:37 |
| dmsimard | SpamapS: I want autohold to trigger for a given tenant, job but only for a specific provider | 19:38 |
| dmsimard | in practice, there's some jobs intermittently failing only on one of many providers and it's a pita to troubleshoot :) | 19:39 |
| clarkb | dmsimard: fwiw that may be an indication we need better logging too | 19:39 |
| SpamapS | dmsimard: would be cool if one could zuul_return something that suggested an autohold, if the admin has allowed it, so that some post-review jobs could determine if they need deeper debugging. | 19:39 |
| SpamapS | Like "oh snap we failed at a weird spot, check this out" | 19:39 |
| dmsimard | clarkb: I don't disagree on improving logging but autohold is very convenient for edge cases :) | 19:41 |
| clarkb | in this case we don't seem to collect logs from that node at all? | 19:42 |
| dmsimard | it seems possible to add a provider filter to autohold, I'm just not very familiar with the database model/relationship | 19:42 |
| clarkb | so I'm not sure its a corner case, we have no logs | 19:42 |
| openstackgerrit | Merged openstack-infra/nodepool master: Ignore removed provider in _cleanupLeakedInstances https://review.openstack.org/608670 | 20:17 |
| *** panda|off has quit IRC | 20:30 | |
| *** panda has joined #zuul | 20:33 | |
| SpamapS | so.. | 20:53 |
| SpamapS | if I want to retry a post job | 20:53 |
| SpamapS | enqueue-ref ? | 20:53 |
| corvus | SpamapS: yep | 20:53 |
| corvus | SpamapS: you can get the magic values from the inventory file | 20:54 |
| SpamapS | Is there a spec for an admin REST API? I seem to recall one being discussed. | 20:58 |
| SpamapS | corvus: ty! | 20:58 |
| SpamapS | corvus: what's the magic value for --trigger? | 20:59 |
| SpamapS | ignored | 21:00 |
| SpamapS | (the scheduler ignored my thing, I mean) | 21:00 |
| SpamapS | trying the name of the driver in --trigger | 21:00 |
| SpamapS | (so github) | 21:00 |
| corvus | SpamapS: should be the name of the connection (and should match something in the pipeline's trigger section) | 21:01 |
| Shrews | SpamapS: https://review.openstack.org/562321 | 21:02 |
| SpamapS | Ah ok I did the name of the connection, yeah. | 21:03 |
| SpamapS | looks like it missed on the files matcher | 21:03 |
| SpamapS | But the same ref did match when the job failed | 21:04 |
| SpamapS | Any known problems with files matchers and enqueue-ref? | 21:04 |
| SpamapS | 2019-01-02 20:59:55,073 DEBUG zuul.layout: Job <Job gmapi-post branches: {MatchAny:{BranchMatcher:master}} source: zuul-base-jobs/zuul.yaml@master#1> did not match files in <Branch 0x7f368d99cac8 GoodMoney/tech refs/heads/master updated c30ebd1a68ef85cc114cb62c24db0b1edc3cf966..40c27a9446ab4d3d2e7d1fe895f7c13bdce28cb0> | 21:05 |
| SpamapS | :-/ | 21:13 |
| SpamapS | cannot get this thing to retry | 21:13 |
| openstackgerrit | Merged openstack-infra/zuul master: Only reset working copy when needed https://review.openstack.org/624343 | 21:35 |
| * SpamapS gives up and just pushes a dead commit to get it to re-run | 21:54 | |
| clarkb | SpamapS: isn't that goign to rely on the files data in the event? but in this case there is no event data? | 21:54 |
| SpamapS | clarkb: Perhaps? No idea how that works. | 21:55 |
| clarkb | I'm guessing this is a mismatch between how enqueue-ref works and your trigger expectations on the pipeline | 21:55 |
| SpamapS | Pretty much a non-starter if you can't retry post jobs though. | 21:55 |
| SpamapS | I'd have expected that the change data comes from the ref. | 21:55 |
| clarkb | in the gerrit driver it comes from the gerrit event iirc | 21:55 |
| clarkb | not sure about github | 21:55 |
| * SpamapS cheats and just has github re-send the notification | 21:56 | |
| clarkb | with the github case it must rely on the event beacuse a PR can have any number of commits in it? | 21:57 |
| clarkb | so the simple ref data isn't sufficient to know what was changed | 21:57 |
| clarkb | though maybe that is what old rev gives you | 21:57 |
| SpamapS | It's not a PR | 21:58 |
| SpamapS | it's a push | 21:58 |
| SpamapS | If it were a PR I could use enqueue. ;) | 21:58 |
| clarkb | well its the same problem right? a push could come with any number of commits | 21:58 |
| clarkb | so you need to know the old base and the new HEAD | 21:58 |
| clarkb | (in order to calculate it locally) | 21:58 |
| SpamapS | Yeah, which should give you the files changed. | 21:58 |
| SpamapS | From git. | 21:58 |
| SpamapS | But I see what you're saying | 21:59 |
| SpamapS | it comes from the event | 21:59 |
| SpamapS | anyway, it might make sense for Zuul to store *everything* needed for a retry somewhere. | 22:04 |
| clarkb | ya or learn the ability to discover that data from git if it is missing | 22:04 |
| SpamapS | Yeah for that one. I just wonder what else we pull from events. | 22:08 |
| SpamapS | (but yeah, now that you say that, it really should always be *git* centric, not *git|gerrit* centric. | 22:08 |
| corvus | SpamapS: there is a case where zuul will internally generate the files list for a PR: https://review.openstack.org/603287 | 22:10 |
| corvus | SpamapS: that could probably be re-used for synthetic events | 22:11 |
| SpamapS | neat | 22:12 |
| SpamapS | yeah seems like we can make things more resilient by using that method when the list isn't already available. | 22:13 |
| *** dkehn_ has joined #zuul | 23:01 | |
| *** dkehn has quit IRC | 23:02 | |
| *** dkehn_ is now known as dkehn | 23:02 | |
| *** rlandy|rover is now known as rlandy|rover|bbl | 23:23 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP: Combine artifact URLs with log_url if empty https://review.openstack.org/628068 | 23:24 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!