GSoC Proposal

[Zero King]

On 4/12/17 10:37 PM, Mojca Miklavec wrote:
> I was talking to someone from the HB community. Apparently they tried
> very hard to make Travis CI work. One of the major problems they had
> other than the time limit (the builder is relatively slow and jobs get
> killed after 50 minutes, so any builds like Qt would fail of course)
> was the fact that it was impossible to upload the binaries from
> "untrusted pull requests" (not sure what that means, in any case, it
> didn't work for them). They set up their own build infrastructure
> almost from scratch. We clearly don't need to upload the result
> anywhere, but the limitations will stay in any case. I would find it
> valuable if we put our effort in something that can be expanded.

Untrusted means I can't run the bot on Travis because any secrets 
available to PRs would be public.
Travis CI is free and I believe this is an advantage for my proposal.
The bot for PRs is not related to Travis and takes more time in my schedule.

> Another option being mentioned was CircleCI (no limitation to upload
> files), but that one has an additional limitation of only 500 free
> minutes per month for OpenSource orgs, so most likely not anywhere
> near enough.

Their macOS builds aren't free. I looked into alternatives but Travis 
seems to be the best.

> What we *could* do is to set up a few more build slaves on the
> "existing" infrastructure (the build slaves could actually be
> anywhere, people could even volunteer to provide access to their
> machines; but I guess the idea would be to eventually set up a few new
> ones next to the existing slaves). The build master could either run
> in the same instance or separately.
>
> The idea would be that people with commit access would have to
> manually approve building of a particular pull request (and then that
> pull request would get a green icon of course once the build is
> complete). When a pull request gets updated/modified, the build could
> be tested again, but it would have to be triggered manually again.

I had this idea in mind but chose the one in the proposal because I'd 
like to finish deployment in GSoC and changing the Buildbot 
infrastructure remotely could cause problems. On Travis whatever I do I 
won't break anything hard to recover or leak any secrets but it's not so 
safe on Buildbot. I consider virtualization and snapshots the last 
defence against evil PRs and prefer to have them.

> The glue code might need some time to be implemented, but it sounds
> like something in the same direction that you already proposed with
> that "go" bot. To be honest, I currently don't know yet what exactly
> would be needed on that part.

Tentative plan:
0. Verify that webhook requests are indeed from GitHub 
(https://developer.github.com/webhooks/securing/)
1. Add update/submission/enhancement based on smart logic (new Portfile 
means submission) or a new "task list" in the PR template.
2. Determine the maintainer of the ports touched, if the submitter is 
one of maintainers for all touched ports not nomaintainer, set the 
maintainer label. If all touched ports are nomaintainer, set the 
nomaintainer label. If a port touched has a maintainer (not PR 
submitter) and is not openmaintainer, set the waitformaintainer label. 
(All label names are tentative.)
3. Send mail to / mention with @ / request review from / assign PRs to 
related maintainers (single maintainer -> assign, etc.). Limit the 
number of maintainers a PR could notify but manual override via 
commenting can be implemented.
4. Send mail to a mailing list (if a new ML for PRs is helpful)

Database:
1. Read Email to GitHub handle mapping from database (if migration to 
GitHub handle in Portfiles didn't finish in time)
2. Cache port to maintainer mapping (?)

> One of the things I really miss is a website with easy access to build
> summary on per-port basis:
> -https://trac.macports.org/ticket/51995#Statistics
> (This might be something that might even be possible to implement as a
> special view right on the buildbot.)

I'm not familiar with the front end techs. Maybe next time.

> Independent: it would be helpful to hear a better
> justification/defence for selecting Go as the language of the "helper
> bot".

Go has a great set of standard libraries and I can use 
https://github.com/google/go-github. Go programs are easy to compile and 
deploy.

-- 
Best regards,
Zero King