<div dir="ltr"><div>+dev-buildbot. If any of you guys are interested in mentoring GSoC, please raise hands.</div><br class="inbox-inbox-Apple-interchange-newline">Hi Mojca,<div><br></div><div><div>Congrats for the GSOC grant! </div><div>We have experience with GSOC, with already a dozen student mentored. </div><div>We didn't manage to get a new grant when the gsoc management team changed, and was a bit disappointed by the lack of explanation on why we weren't chosen. So we gave up trying.</div><div><br></div><div>I liked the GSOC mentoring though, and I would be glad to do it again.</div><div><br></div><div>I acknowledge your pain points on Buildbot eight, and agree that nine will probably not help that much with the current turnkey visualisation plugins.</div><div>Other people are also frustrated by the nine version of the waterfall, including the webkit people <a href="https://github.com/buildbot/buildbot/issues/3884">https://github.com/buildbot/buildbot/issues/3884</a></div><div>I added lengthy explaination in this issue on why it is like that and why it is not easy to improve. But help is appreciated.</div><div><br></div><div>My suggestion for webkit is also valid for macports. What you may need is a new UI plugin, which is carefully crafted for your requirements.</div><div><br></div><div>I think this is a very good match for a GSOC project. This would be a project to address your points 3, 4 and 5.<br></div><div>I think this can be done by recruiting a front-end student. Probably this kind is a bit easier to recruit, and the problem are simple enough to enunciate clearly for a student.</div><div>The project might need to develop some python code in order to speed-up the queries (like the one to matches every builds associated to a change <a href="https://github.com/buildbot/buildbot/issues/3927">https://github.com/buildbot/buildbot/issues/3927</a> ). This is something that I could help with if the student is not confident to do the backend part by him/herself.</div><div><br></div><div><br></div><div>For point 1. Buildbot nine now has several tools to mitigate security issues related to testing PRs.</div><div>- SecretManager can restrict the access of secrets to builds happening after patch is merged</div><div>- LatentWorkers can make sure a new VM is spawn for each build, but probably the MacOs part is not as easy on your side.</div><div>In any case it is a tough problem that is not easy to resolve as basically the goal of the CI is to give developers access to machines, a malicious developer will easily take control of that machine.</div><div>A potential project for this problem would be to add some extra triggering criterias for building a MR, like the approval of at least one trusted member of the team.</div><div>It looks like a lone a bit short subject for GSoC, I would say.</div><div><br></div><div>For point 2, eight and nine both have ways to prioritize buildrequests according to various criterias. The way did change a little bit, and nine is a little bit better for that, but I don't think it is significant for what I understand from your usecase.</div><div><br></div><div>There might be enough of a workload for a GSoC project if you combine point 1 and point 2, but this will be a little bit more difficult to mentor as it is very specific problems which for me could use a bit more experienced people to conduct.</div><div><br></div><div>Regards</div><div>Pierre</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 14, 2018 at 9:55 AM Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Pierre,<br>
<br>
MacPorts got accepted for GSOC 2018.<br>
<br>
A while back we discussed some aspect of BuildBot that could be<br>
improved (I remember something about a GSOC student doing a poor job<br>
implementing waterfall for buildbot nine?).<br>
<br>
A short question: would anyone from your team be willing to (co)mentor<br>
a potential applicant working on buildbot?<br>
<br>
A long explanation follows.<br>
<br>
We are currently using buildbot eight. Reasons why:<br>
- We wrote the setup in 2016 when nine was not totally stable yet and<br>
we wanted to play a bit on a safer side. Nobody did any major rewrite<br>
since then, but we plan to have an in-person meeting for an extended<br>
weekend around March 10 in Slovenia and trying to migrate to version<br>
1.0 is on agenda for that meeting as well. (If anyone from your team<br>
needs some hacky holidays on snow, just let me know.)<br>
- Back in 2016 the waterfall in nine was relatively inferior to eight,<br>
at least for our needs. On the one in version nine it was much more<br>
difficult to see anything.<br>
<br>
Now, let me admit that I didn't look too closely at buildbot<br>
development since 2016, I do feel sorry that we were are able to use<br>
some of the features existing in version nine, but just to explain<br>
that please excuse me if I'm not aware of all the development that<br>
must have happened since.<br>
<br>
Here's what we are currently missing:<br>
<br>
1.) A safe setup. Someone wrote travis setup for testing pull requests<br>
last year. Travis has lots of drawbacks, the main one being that most<br>
of the PRs simply time out, the less severe one that we are not able<br>
to test on arbitrary setups (it would be super useful if we had the<br>
ability to occasionally test changes on Mac OS X 10.6 for example).<br>
I'm pretty sure that there's nothing buildbot itself can do about it,<br>
but we had no clue if there's a painless way to "make our own<br>
buildbot-based travis-like service" that would not be susceptible to<br>
malicious attempts.<br>
<br>
2.) I believe this is a specific deficiency of buildbot eight, but we<br>
have troubles controlling the order of scheduled builds. (We have one<br>
builder that checks which ports need to be built and then sends ten<br>
jobs to another builder; those jobs then get executed in random order<br>
which is somewhat painful. I'm sure there's a workaround as well, but<br>
also pretty positive that 1.0 works better and can work in a<br>
completely different way anyway.)<br>
<br>
3.) One of the biggest "pains" we are facing is that there's almost no<br>
way to check whether commit nr. 1234567 failed or succeeded on various<br>
builders. One can do some kind of "bisection" in either waterfall view<br>
or by manually changing numbers for a particular builder, but that's<br>
waaaaay too tedious and what we usually do is simply run the build<br>
again and check the results from that new build.<br>
<br>
4.) An equally big pain is that we would like to have an overview of<br>
all the builds of package "foo". On "normal" buildbot setups one would<br>
have one builder for package "foo", one builder for package "bar" etc.<br>
We need to build all packages on the same builder (we have tens of<br>
thousand of packages, building one package potentially requires<br>
building 20 other ones first) and that obfuscates the results. The<br>
problem is that we cannot show any "expected time left" based on<br>
previous statistics, that we cannot do any port/package-based summary<br>
etc. I would like to be able to pick a package and show when it was<br>
built, at which version and on which builders it failed to build (and<br>
at which step: while installing a dependency or while building the<br>
package itself). It would also be helpful to be able to select a<br>
committer and display the history of all of his successful/failed<br>
builds.<br>
<br>
5.) Waterfall on nine/1.0: Last time I checked (long time ago) there<br>
was no text, just green and red boxes. For us that's hardly useful, we<br>
need to see the name and phase of the ports being built. You said this<br>
should be configurable in web though.<br>
<br>
Some of these problems could be remedied by writing our own set of<br>
scripts: json parser for buildbot logs, database and our own website<br>
to display the results. But I'm pretty sure that some of these<br>
problems could be addressed from the buildbot core code in a way that<br>
could be beneficial for other projects as well.<br>
<br>
What I would potentially like to see done during a GSOC project would<br>
be a combination of buildbot codebase extension (with what makes sense<br>
for other projects) + fine-tuning master.cfg for our own specific<br>
setup & needs. But even if just the first part is done (implementing<br>
the required functionality on the buildbot side while leaving<br>
fine-tuning to us) would be fine by me. But this is only doable in a<br>
very close collaboration with a (co)mentor from buildbot.<br>
<br>
Please let me know what you think of this and if there's a way to<br>
merge our forces and interests together. Feel free to forward this (or<br>
perhaps reword it into "your own language" first) to the mailing list<br>
if you feel others have some valuable feedback or opinion. I don't<br>
have sufficient insight into what is currently possible and what would<br>
need to be implemented and how difficult that would be.<br>
<br>
Our current setup is here:<br>
    <a href="https://build.macports.org/waterfall" rel="noreferrer" target="_blank">https://build.macports.org/waterfall</a><br>
<br>
Thank you,<br>
    Mojca<br>
</blockquote></div></div>