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
