| *** saneax-_-|AFK is now known as saneax | 04:22 | |
| *** isaacb has joined #zuul | 06:01 | |
| *** Cibo_ has joined #zuul | 06:57 | |
| *** Cibo_ has quit IRC | 07:27 | |
| *** bhavik1 has joined #zuul | 07:27 | |
| bhavik1 | @here, while trying out zuul latest master, with sql setup I found an error for " File "/usr/lib/python2.7/site-packages/zuul/reporter/sql.py", line 79, in report | 07:38 |
|---|---|---|
| bhavik1 | build.start_time), | 07:38 |
| bhavik1 | TypeError: a float is require" after some debugging forund that I've "noop" job for one of the pipeline, and for some reason start_time value is 'None' in case "noop" job | 07:38 |
| *** Guest68960 has quit IRC | 08:14 | |
| *** mgagne has joined #zuul | 08:20 | |
| *** mgagne is now known as Guest11443 | 08:20 | |
| *** bhavik1 has quit IRC | 08:47 | |
| *** hashar has joined #zuul | 09:00 | |
| *** isaacb has quit IRC | 09:34 | |
| *** isaacb has joined #zuul | 09:35 | |
| *** isaacb has quit IRC | 09:47 | |
| *** hashar has quit IRC | 09:59 | |
| *** hashar has joined #zuul | 10:04 | |
| *** wznoinsk has joined #zuul | 10:55 | |
| *** Cibo_ has joined #zuul | 11:09 | |
| *** yolanda has quit IRC | 11:17 | |
| *** yolanda has joined #zuul | 11:19 | |
| *** abregman has joined #zuul | 11:34 | |
| *** abregman has quit IRC | 12:04 | |
| *** Cibo_ has quit IRC | 12:23 | |
| *** saneax is now known as saneax-_-|AFK | 12:27 | |
| *** Cibo_ has joined #zuul | 14:56 | |
| *** Cibo_ has quit IRC | 15:08 | |
| *** isaacb has joined #zuul | 15:21 | |
| *** Cibo_ has joined #zuul | 15:31 | |
| *** Cibo has joined #zuul | 16:02 | |
| *** Cibo_ has quit IRC | 16:05 | |
| *** Cibo has quit IRC | 16:07 | |
| *** Cibo_ has joined #zuul | 16:07 | |
| *** bhavik1 has joined #zuul | 16:48 | |
| *** bhavik1 has quit IRC | 16:48 | |
| *** Cibo_ has quit IRC | 16:54 | |
| SpamapS | jlk, jesusaur, jeblair : I think we should chat a bit about github patch porting. Specifically, how the planned Changeish/Ref differences will hamper/help the effort. | 17:32 |
| jlk | I'm game. | 17:32 |
| jlk | I've got one attempt in teh works that's just copying over all the content we're running, and touching it up a bit for new paths and for where code should live, but it would be a massive single commit | 17:32 |
| jeblair | yeah, i think that's something we should address beforehand | 17:32 |
| jlk | otherwise, it'd be lots of commits from the existing patch set, munged for paths as they're checked in, with all the old change IDs unless I touch them to make them new | 17:33 |
| jeblair | i think it would be good to review a patch series in some form. i'm not opposed to reviewing it on the v2 branch to get the story and then merging a squashed patch into v3, or doing followup fixes in v3, or munging each of the v2 patches for v3. whatever (other than single-massive-patch-to-review) works. :) | 17:35 |
| jeblair | SpamapS: do you know if anyone has volunteered to take on the change/ref work? | 17:36 |
| jlk | well, I'm volunteering to do the work | 17:36 |
| jeblair | oh excellent :) | 17:36 |
| SpamapS | jeblair: there you go :) | 17:37 |
| jlk | It's.. probably not worth trying to merge things on v2.5, but having somebody look through the patch set and offer overall commentary, could certainly help with v3 work. | 17:38 |
| SpamapS | jlk: https://storyboard.openstack.org/#!/story/2000781 <-- | 17:38 |
| SpamapS | jeblair: also, I feel like we reached a milestone last week, and it might be good to re-evaluate the contents of the backlog (and maybe todo) given what we've learned. | 17:39 |
| jlk | oh THAT | 17:39 |
| jlk | I'm not sure I'm volunteering for that... | 17:39 |
| jlk | let me read up on it | 17:39 |
| jlk | I was completely misunderstanding you | 17:40 |
| jeblair | my general thought for why we should do it first is that the 'change' object is a pretty leaky abstraction. it's fairly gerrit-centric, yet is used just about everywhere in zuul. in my mind, it can be abstracted for other systems, but it's clunky. the thing that *every* (git-based) system can agree on is that we operate on refs. so having the Ref class be the base that everything expects internally in zuul, and then having a change class ... | 17:40 |
| jeblair | ... that builds on that which matches gerrit things, and similarly, a pullrequest class, will make the api much more understandable. | 17:40 |
| SpamapS | jeblair: if I understand it correctly, we'd end up with Ref throughout Zuul, but Change would be contained to the gerrit driver? | 17:41 |
| SpamapS | jlk: I wouldn't mind taking the work on if you want to back away slowly. ;-) | 17:42 |
| jlk | hah. | 17:42 |
| jeblair | SpamapS: perhaps change inherits from ref and adds fields (so that the launcher can add those fields to jobs) | 17:42 |
| jlk | Could we pair maybe? or I'll help review? | 17:42 |
| jlk | I'll have to understand this anyway to modify the github patches I think. | 17:42 |
| jeblair | we may also need to standardize the 'enhancements' to ref. for instance, PullRequest(Ref) and Change(Ref) should both have a .branch attribute so that we know what branches they are against. | 17:44 |
| jeblair | (but strictly speaking, a Ref itself doesn't have a branch) | 17:44 |
| SpamapS | jeblair: feels like maybe there's a missing abstraction between ref and PR/Change that helps us express the LCD | 17:45 |
| SpamapS | jlk: yeah that might be the most efficient way. team up to fill in the gaps since you're far more familiar w/ the github code and I've been diving into Zuul's internals a while now | 17:45 |
| jeblair | SpamapS: yeah. hopefully we can find something to call it other than "Changeish". :) | 17:47 |
| SpamapS | jeblair: we could also go through the exercise of evaluating other systems than github/gerrit from the outside (without actually writing a driver) to see what these systems all seem to have in common and then make sure the launcher only hard-depends on those features (and optionall exposes the things that are unique to gerrit/github) | 17:47 |
| SpamapS | optionally | 17:47 |
| jlk | things other than git, or things other than gerrit/github that are still based on git? | 17:48 |
| SpamapS | things git based, but not gerrit/github | 17:48 |
| SpamapS | so gitlab basically | 17:48 |
| jlk | yeah, pretty sure it mirrors github in that respect. | 17:48 |
| clarkb | bitbucket is also popular | 17:48 |
| jlk | bitbucket might be more interesting since it's not a github clone | 17:49 |
| SpamapS | The only requirement would be that it has clear docs so we could spend less than a day on the thought experiment. :) | 17:49 |
| jeblair | yeah, we're so far down the git road at this point, i don't want to design for not-git yet. maybe someday, but let's get a thing out the door. :) | 17:49 |
| * SpamapS doesn't even think there are things that are not git in the world anymore | 17:49 | |
| SpamapS | hg is just a git frontend right? ;-) | 17:50 |
| jeblair | SpamapS: fortunately, most of them have git gateways :) | 17:50 |
| clarkb | even launchpad can do git now apparently | 17:50 |
| SpamapS | yep | 17:50 |
| jlk | so after zuul, we should tackle a launchpad replacement, right? :D | 17:51 |
| SpamapS | fortunately the area was sparsely populated when that 7.9 magnitude quake landed on launchpad. ;) | 17:51 |
| SpamapS | jlk: we already have one? ;) | 17:51 |
| SpamapS | https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/pullrequests | 17:52 |
| jlk | so, anyway, to bring this convo back | 17:52 |
| SpamapS | "This method attempts the retrieve results from a cache" | 17:52 |
| jlk | aside from the Changeish refactor which I can fudge in when appropriate, it sounds like it would be preferable to present the github functionality as a set of changes | 17:53 |
| jlk | which I can attempt to do from the 2.5 patch set, but with some intelligent squashing of bugfix changes and obvious things to squash together | 17:53 |
| jlk | and present it as a set of things on the v3 feature branch. | 17:54 |
| jeblair | jlk: yes please and thank you | 17:54 |
| SpamapS | jlk: ok, and I'll take a stab at a Ref/Change split and collaborate with you as early as possible to make sure I'm not making your work harder. | 17:56 |
| persia | If there is a desire to look at a very different git server, gitano may be interesting. | 17:58 |
| *** hashar has quit IRC | 17:58 | |
| jlk | yay good plans | 18:00 |
| SpamapS | persia: Gitano sounds like Boitano.. https://cdn.meme.am/cache/instances/folder765/28301765.jpg | 18:00 |
| persia | SpamapS: https://www.gitano.org.uk/ (but I suspect the favicon is aimed directly that the mentioned meme) | 18:01 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Plumb job variables through to ansible https://review.openstack.org/438653 | 18:02 |
| *** isaacb has quit IRC | 18:14 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Plumb job variables through to ansible https://review.openstack.org/438653 | 18:24 |
| jlk | jeblair: SpamapS: would it help if, when I cherry pick, I somehow generate a new Change-Id line in the commit message? | 18:25 |
| jlk | so that it doesn't conflict with the existing change id on the v2.5 patch set? | 18:25 |
| jeblair | jlk: since it's on a different branch, it should be fine to keep the change-id | 18:25 |
| jlk | cool. | 18:25 |
| jeblair | jlk: desirable, in fact, i think, since it lets us cross-reference things easily | 18:26 |
| jlk | okay | 18:26 |
| jeblair | jlk: (only downside is if we use it as the target of a depends-on -- zuul wants changes merged in all branches before it will let a dependency merge). but i don't think that's an issue in this case | 18:26 |
| jlk | okay. I shouldn't mark depends on per se, just put them all on the same topic branch and review topic? | 18:27 |
| jeblair | jlk: yes | 18:27 |
| jeblair | pabelanger: should we land your ptg job patches? | 18:29 |
| jesusaur | jlk: jeblair: SpamapS: I think one of the harder parts of making Change a subclass of Ref will be around the ChangeishFilter code paths | 18:33 |
| jlk | yeah, that's going to be fun, and that's actually a point where we _want_ to be able to extend and define that inside the driver instead of in core zuul code | 18:34 |
| SpamapS | right | 18:34 |
| pabelanger | jeblair: sure | 18:34 |
| SpamapS | that's really the main part where we want that line to be clear | 18:34 |
| jeblair | jlk, jesusaur, SpamapS: yes. we may need to move ChangishFilter into the driver interface (and rename it) to set an api for that, and then have Trigger classes instantiate and return their own subclasses of the filter | 18:36 |
| jeblair | also source classes should do the same for pipeline filters | 18:36 |
| jesusaur | also, maybe rename them to TriggerFilter and PipelineFilter because I frequently forget which filter is which | 18:37 |
| jeblair | yeah, those sound good | 18:38 |
| * SpamapS takes notes | 18:41 | |
| *** abregman has joined #zuul | 18:53 | |
| *** Cibo_ has joined #zuul | 18:54 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Plumb job variables through to ansible https://review.openstack.org/438653 | 18:55 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Publish python-linters jobs to apache https://review.openstack.org/437938 | 19:05 |
| jeblair | pabelanger: ^ removed WIP from commit msg | 19:07 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Create python-linters job https://review.openstack.org/437059 | 19:10 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Copy logs to launcher https://review.openstack.org/437700 | 19:11 |
| pabelanger | jeblair: l | 19:14 |
| pabelanger | err | 19:14 |
| pabelanger | k | 19:14 |
| jeblair | mmm | 19:14 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Create provider 'launcher-id' setting https://review.openstack.org/438677 | 19:18 |
| pabelanger | jeblair: mordred: ^thoughts? Would love some feedback | 19:19 |
| jeblair | pabelanger: at a quick glance, that looks roughly like what we want, but i think the name is misleading | 19:21 |
| mordred | pabelanger: looks great - I left a might-want-to comment | 19:21 |
| pabelanger | ya, will to change | 19:21 |
| jeblair | pabelanger: it's not the id of the launcher -- a single nodepool system can have many launchers, all of which do have a name (and we know it) | 19:21 |
| jeblair | pabelanger: but rather, what we're describing is an id for the nodepool 'system'. | 19:22 |
| jeblair | the conceptual collection of related launchers. | 19:23 |
| jeblair | tbh, this is a little weird because as clarkb points out, normally having separet providers is sufficient. | 19:23 |
| jeblair | and of course, you can have separate zookeeper chroots as weel. | 19:24 |
| jeblair | well | 19:24 |
| jeblair | we're only in this position because we want to share images across different nodepool launching systems (and we only want to do that because we don't have the v2.5 shim) | 19:24 |
| jeblair | so we might want to add this option with a "(deprecated)" flag :) | 19:25 |
| clarkb | right, I suggested we just run two systems | 19:25 |
| clarkb | and not share images | 19:25 |
| pabelanger | sure | 19:25 |
| pabelanger | so, nodepool_id works? | 19:25 |
| jeblair | pabelanger: yeah, that wfm. | 19:26 |
| jeblair | btw, https://review.openstack.org/438653 should let us start playing around with removing some of the stuff we hard-coded at the ptg. | 19:28 |
| pabelanger | cool, will look shortly | 19:33 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Add nodepool-id to provider section https://review.openstack.org/438677 | 19:34 |
| timrc | pabelanger: Interesting.. https://github.com/jakubplichta/grafana-dashboard-builder | 19:36 |
| pabelanger | neat! | 19:37 |
| pabelanger | jeblair: mind if we land: https://review.openstack.org/#/c/436195/ adds recheck to zuulv3-dev.o.o | 19:49 |
| *** hashar has joined #zuul | 19:53 | |
| jeblair | pabelanger: ++ end the new patchset madness :) | 20:04 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Add nodepool-id to provider section https://review.openstack.org/438677 | 20:17 |
| *** Guest11443 is now known as mgagne | 20:57 | |
| *** mgagne has quit IRC | 20:57 | |
| *** mgagne has joined #zuul | 20:57 | |
| jeblair | ok_lanes = MAP[task['status']] | 21:20 |
| jeblair | KeyError: u'invalid' | 21:20 |
| jeblair | SpamapS: whoops ^ | 21:20 |
| jeblair | (from my cronspam) | 21:20 |
| SpamapS | jeblair: did we break the board? | 21:22 |
| SpamapS | new status in storyboard maybe | 21:22 |
| jeblair | SpamapS: looks like i forgot that in my script; patching it now. | 21:22 |
| SpamapS | we've had invalid tasks for a while | 21:22 |
| SpamapS | I think | 21:22 |
| SpamapS | maybe not :) | 21:22 |
| jeblair | SpamapS: maybe we had 0 invalid zuulv3-tagged tasks until now? | 21:23 |
| SpamapS | OH | 21:23 |
| SpamapS | yes | 21:24 |
| SpamapS | haha | 21:24 |
| SpamapS | jeblair: I just tagged 2000773 with zuulv3 (with my new tag editting feature in boartty ;) | 21:24 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Storyboard: Support invalid tasks in update script https://review.openstack.org/438704 | 21:24 |
| jeblair | SpamapS: it worked! :) | 21:24 |
| SpamapS | jeblair: clearly | 21:24 |
| SpamapS | jeblair: what's not working for me is locally creating new tags because sqlalchemy fail | 21:24 |
| SpamapS | trying to see how to make it magically handle writing to the relation or something | 21:25 |
| jeblair | SpamapS: hrm.... i'll continue in -infra | 21:26 |
| SpamapS | meeting in 60s yes? | 21:58 |
| jeblair | yep | 21:58 |
| jeblair | Zuul meeting in #openstack-meeting-alt | 22:01 |
| dmsimard | Hello Zuulers, you might be interested in this ARA thing I'm working on -- care to give some feedback on some UI rework ? | 22:32 |
| dmsimard | Before: http://logs.openstack.org/98/435698/1/check/gate-openstack-ansible-os_magnum-ansible-func-ubuntu-xenial/329f931/logs/ara/ | 22:33 |
| dmsimard | After: http://46.231.133.111/index.html | 22:33 |
| rbergeron | dmsimard: come to the meeting and share? #openstack-meeting-alt (i'm sure jeblair can wiggle you into our unagenda) | 22:36 |
| dmsimard | rbergeron: sure | 22:36 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add generic tox jobs https://review.openstack.org/438281 | 22:54 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add generic tox jobs https://review.openstack.org/438281 | 22:55 |
| *** hashar has quit IRC | 22:59 | |
| dmsimard | clarkb: o/ what do you want to ctrl+f ? | 23:06 |
| clarkb | dmsimard: if I'm looking for a specific task for exampel I can just ^F and find it | 23:06 |
| clarkb | dmsimard: I generally dislike website (like gerrit) that implement their own search into page content as a reaplcement for the browser | 23:06 |
| clarkb | since the broswer tends to be better at it then a bunch of js served by eg gerrit | 23:06 |
| clarkb | dmsimard: that said there is probably a balance to be reached due to possibility for really large numbers of tasks | 23:07 |
| dmsimard | clarkb: right -- so now there's a search field instead, yes | 23:07 |
| dmsimard | and yes, this was also implemented due to scalability issues | 23:07 |
| dmsimard | OSA has playbooks with 7k tasks :) | 23:07 |
| dmsimard | that said, I think the new search boxes are great -- they allow you to filter by status, host and task action/name easily | 23:08 |
| *** abregman has quit IRC | 23:08 | |
| clarkb | dmsimard: I am just really scared of them after gerrit implemented one | 23:09 |
| clarkb | its slower and less accurate than the one firefox provides | 23:09 |
| dmsimard | the search boxes aren't tied to a backend, though | 23:09 |
| dmsimard | i.e, storyboard and gerrit both query the backend | 23:10 |
| clarkb | dmsimard: no gerrits is all frontend | 23:10 |
| clarkb | dmsimard: when searching through code diffs | 23:10 |
| clarkb | dmsimard: it replaces your browser's ^F functionality | 23:10 |
| dmsimard | oh, yeah, that | 23:10 |
| dmsimard | I meant, for example, the change search box where it will try to autocomplete your search as you type your query | 23:11 |
| dmsimard | I'm with you on that, I don't like ctrl+f hijacking :/ | 23:11 |
| *** saneax-_-|AFK is now known as saneax | 23:16 | |
| openstackgerrit | Merged openstack-infra/nodepool master: Add nodepool-id to provider section https://review.openstack.org/438677 | 23:22 |
| jeblair | dmsimard: http://imgur.com/a/ZTNjq | 23:32 |
| jeblair | dmsimard: it took me a few minutes to realize all the interesting things are scrolled off the right of my screen. | 23:32 |
| dmsimard | jeblair: already working on that one -- it works okay on my screen resolution (and surprisingly functional on my phone) but need to tweak a bit for "in-between" :) | 23:33 |
| dmsimard | it's indeed requesting a bit too much width by default | 23:33 |
| dmsimard | you know: http://i.imgur.com/M3Fvej7.jpg | 23:34 |
| jeblair | dmsimard: yeah, it looks like 990 pixels wide is about optimal for me -- it folds the things down under the playbook there | 23:35 |
| jeblair | dmsimard: lol :) | 23:35 |
| dmsimard | If only ARA had a API, you could do an aratty :P | 23:35 |
| jeblair | i hope the text mode interface to ansible is ansible :) | 23:36 |
| * dmsimard wants to restructure ARA with an API eventually | 23:36 | |
| dmsimard | well, actually, ara does have a CLI client based on cliff so it's not far off the python-openstackclient UX | 23:36 |
| dmsimard | It's taken a bit of a back seat since CLI is boring and people are more interested in the UI but there's definitely some use cases there | 23:37 |
| jeblair | dmsimard: some of the expansion options also look better in smaller windows than my in-between 1280 wide screen | 23:37 |
| jeblair | dmsimard: as in, the tables have to scroll if the window is wide, but don't if it is small (which is counterintuitive) | 23:38 |
| dmsimard | scroll horizontally ? | 23:38 |
| jeblair | dmsimard: yep | 23:38 |
| jeblair | the host list table scrolls at 1280x -- it only gets as far as "UNREACHA" in the last column | 23:39 |
| dmsimard | Seen that on my phone which was fairly expected -- I'll have to work so that it behaves well on desktop-ish resolutions | 23:39 |
| jeblair | dmsimard: and one more minor thing -- the file list may be easier to read if set left justified rather than centered. | 23:40 |
| jeblair | (common paths line up and make it easier to scan the list of files) | 23:40 |
| dmsimard | jeblair: I want to rework the file list, I just haven't figured out how yet .. I want to display something that looks like this: https://www.patternfly.org/pattern-library/widgets/#bootstrap-tree-view | 23:43 |
| jeblair | dmsimard: that would be ideal | 23:43 |
| * dmsimard nods | 23:43 | |
| jeblair | dmsimard: i'm personally not a fan of pagination | 23:43 |
| dmsimard | I need to generate the JSON dict that the treeview thing expects from a list of paths | 23:43 |
| dmsimard | but it's sort of breaking my brain, spent too much time on it | 23:44 |
| jeblair | dmsimard: i would much rather have a big list viewable in my browser and searchable (and if it were also filterable, that would be okay, but just the ability to see everything at once is important to me) | 23:44 |
| jeblair | i can't construct a mental big-picture model of what's going on if i have to click next all the time. | 23:45 |
| jesusaur | i know it's an old change to the master branch, but i would appreciate reviews on this zuul-cloner feature: https://review.openstack.org/#/c/227955 | 23:45 |
| jeblair | jesusaur: i thought we had a check that required the zuul ref if zuul_project was set | 23:46 |
| dmsimard | jeblair: I hear that, and I sort of feel that way too. I will probably have to make it configurable due to scalability issues. Otherwise you have something like this that happens: https://www.youtube.com/watch?v=zT1l-rFne-Q&t=188 (see the endless list of things) | 23:47 |
| dmsimard | and that endless list of things is actually fairly tame, I've seen much much worse in larger scale playbooks | 23:47 |
| jeblair | dmsimard: i was going to say, that seems perfectly manageable to me! | 23:47 |
| jesusaur | jeblair: in the jobs or in zuul-cloner? | 23:48 |
| rbergeron | "thats as big as i thought it was":) | 23:48 |
| dmsimard | jeblair: we're in a land of 25MB worth of openstack logs in a single page :p | 23:48 |
| jeblair | jesusaur: i thought in zuul-cloner, but maybe we lost that somewhere along the way? | 23:48 |
| rbergeron | vs. omg where is all the things?! | 23:48 |
| jesusaur | jeblair: 'check that in the job' is a reasonable approach, but in BonnyCI we've seen a couple gate tests run against master due to clone/fetch errors | 23:49 |
| jeblair | jesusaur: no i'm not saying check it in the job | 23:49 |
| jeblair | jesusaur: i'm saying that i think it is an error if we fail to fetch a ref for $ZUUL_PROJECT on $ZUUL_BRANCH | 23:50 |
| dmsimard | jeblair: I value your time a *lot*, thanks for even remotely looking at it. Feedback much appreciated :) | 23:50 |
| jeblair | jesusaur: and i thought at some point zuul-cloner checked that. perhaps we accidentally removed it, or perhaps i'm mistaken and that was just in gerrit-git-prep. | 23:50 |
| jesusaur | jeblair: hm, maybe that's something that was lost along the way (or otherwise isn't in the version of zuul we're deploying) | 23:51 |
| jeblair | jesusaur: but i do agree with you that, at least in that case, it is an error. i think it can be solved without a new option though. | 23:51 |
| jeblair | jesusaur: i don't think that problem will exist in v3 though, since the jobs won't require zuul-cloner to operate. | 23:52 |
| jesusaur | oh, true; it's a non-problem when we push the ref rather than fetch it :) | 23:53 |
| jeblair | yeah, that's one of my favorite things about that change | 23:55 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
