/srv/irclogs.ubuntu.com/2025/02/14/#launchpad-dev.txt

guruprasadcjwatson, do you have a few spare minutes to answer some questions about buildbot? I see that you have been contributing to the maintenance of the Debian buildbot package recently. I wanted to confirm that the package still doesn't have the plugins and web bits that lpbuildbot uses, right? We are evaluating upgrading to a model similar to the LP charms where we install the vendored deps using pip and wanted to confirm. Also, if you have any 08:03
guruprasadadvice, please let us know. Thanks!08:03
guruprasadWe want to get off the manual set up that we have now for lpbuildbot soon08:04
cjwatsonguruprasad: Most of the remaining bits in lpbuildbot were pretty custom for LP.  I don't think any of them went upstream, though I haven't checked in any detail and there could be odds and ends that are simplified by newer versions.09:57
cjwatsonguruprasad: You definitely need some kind of pinning (whether that's via choice of Ubuntu version with associated system packages, or pip), since some of the bits in lpbuildbot are very version-delicate.  If I were trying to port to a new version then I'd be particularly careful about things such as GitPoller which involved cloning-and-hacking of bits of buildbot to change particular behaviours - 10:00
cjwatsonyou'd want to compare against the version they were designed for, and then see which changes from buildbot you need to incorporate into the lpbuildbot code.10:00
cjwatsonguruprasad: Though actually it looks as though the need for that cloned-and-hacked GitPoller might go away with buildbot 4.1.0.  That'd be nice.10:02
cjwatsonguruprasad: If you can get authentication working (I think either Tom or I tried but failed for some reason I forget), then some other things can probably be simplified - you might be able to use buildbot's own support for forcing builds rather than the hack that's currently in lpbuildbot for that.10:05
cjwatsonguruprasad: buildbot seems to have support for subunit observing nowadays, and it may be worth seeing whether LP can use that rather than injecting its own (I _think_ the code in lpbuildbot dates from before buildbot supported this).10:06
cjwatsonguruprasad: The only other bit of any complexity is AggregatingScheduler.  I've long since paged out the details of that so you're on your own there :)10:08
guruprasadThanks cjwatson. This is helpful.10:21
guruprasadI had a lot of trouble reading and understanding the AggregatingScheduler code but at least resigned to understand what it tries to do at a high level instead of trying to understand every line of Twisted code in it.10:22
guruprasadI also wonder if we can drop that and live with the default scheduler and its drawbacks in comparison to the AggregatingScheduler if porting it ends up being too difficult.10:23
guruprasadSince we do not understand a lot of what most of the custom code does, there is also a thought about starting with vanilla buildbot, finding out what doesn't work well and look into customizing those.10:24
guruprasadInstead of assuming that all the lpbuildbot customizations are needed and trying to port them forward.10:24
cjwatsonI would not recommend that approach ...10:27
cjwatsonIt's not so much custom code that it's impossible to understand.10:27
cjwatsonYou could drop the AggregatingScheduler if you're OK with the consequence, which is that if you land several changes in close succession then buildbot will get backed up because it will do a test run for each in turn.10:28
guruprasadI think our challenges are two-fold - lack of prior Twisted knowledge (this can be bridged) and lack of understanding of buildbot itself and its patterns (this a lot more tough)10:28
cjwatsonThat might be not quite so bad now that it's faster than it used to be.10:28
guruprasadYeah, I managed to understand what the AggregatingScheduler does.10:29
cjwatsonI don't _think_ the default scheduler will do a run for each individual commit introduced by a merge commit, but you'd probably want to rig up something to test that if you were going to drop AggregatingScheduler.10:29
guruprasadThe builds run in ~1 hour these days. So it might be okay to just rely on the treeStableCount used by the default scheduler and see how well it works/doesn't work10:30
cjwatsonHonestly I think if you got onto 4.1.0, dropped GitPoller, maybe switched to its built-in subunit observing, and maybe were able to use the default scheduler, the rest of lpbuildbot would not remotely be a problem to maintain10:30
cjwatson(by which I mean >=4.1.0, not specifically that version)10:30
guruprasadDo you know if there is a path forward at all to get all the plugins in the upstream deb package? It has been many years and releases.10:30
guruprasadAnd I do not see any information pointing to the upstream issues about this getting resolved.10:31
cjwatsonNo idea, sorry.  I've been doing basic package maintenance but only really superficial stuff.10:31
guruprasadNo problem, thanks.10:31
guruprasadThis is so helpful already.10:31
cjwatsonhttps://bugs.debian.org/1004344 looks like the main bug report about this.10:32
cjwatsonBut my appetite for digging through JS packaging stuff is fairly low.10:32
cjwatsonI can do Python!10:32
cjwatsonRe challenges: if one of your problems is lack of understanding of buildbot itself etc., then exactly what you _don't_ want to do is to throw away code written by previous people who've beaten their heads against this without first working out what it does.10:34
cjwatsonIf you were all buildbot experts, then I'd absolutely say you could start with vanilla and it would be a quick job to figure out the necessary customizations.10:35
cjwatsonBut when you have a knowledge gap, IMO that's backwards.10:35
guruprasadOkay, that makes sense10:36
guruprasadOur only concern with not throwing away the existing code is that it is for a buildbot version so old that a lot of those things may not be needed any more.10:37
cjwatsonBy all means once you upgrade and find that something is superfluous _then_ throw it away :)10:37
guruprasadBut I guess we have to start somewhere and looking at the existing customizations and the version they were written for is a good place.10:37
cjwatsonI forget what you're on at the moment.  xenial?  Or was the buildbot manager still stuck on precise or something?10:38
cjwatsonI thought we got it onto xenial.10:38
guruprasadbionic with a hand-ported, manually setup package that you installed somehow.10:39
cjwatsonOh, that's not so bad.10:39
cjwatsonWhat buildbot version?10:39
guruprasadI think it is the xenial package that you forward ported.10:39
guruprasad0.8.12 iirc10:39
cjwatsonDid I happen to leave records of why?  I wonder if that was because we still had to support xenial builders at the time.10:40
cjwatsonAnd we only dropped xenial builders shortly before I left10:40
guruprasadI think one of the reasons I remember reading you mention somewhere was that the xenial version was the last one that had all the plugins and web stuff bundled in.10:41
guruprasad*the xenial version of the buildbot package10:41
cjwatsonHm.  OK, I don't remember that but I guess it's possible.10:41
guruprasadFrom bionic onwards, they were dropped from the debian package, I think10:41
cjwatsonI suppose that's the Debian bug above then.10:41
guruprasadYes10:41
cjwatsonSo yeah, might not be silly to see if you can get an equivalent setup with pip, and then it should be easy enough to try upgrading gradually.10:42
cjwatsonI might get round to looking at that Debian bug eventually but it's unlikely to be any time soon - at the moment I don't have a need for it10:43
cjwatsonOr a customer who cares10:43
guruprasadYeah, I understand10:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!