On Apr 7, 2018, at 07:02, db wrote:
> On 7 Apr 2018, at 07:47, Mojca Miklavec wrote:
>> No, because that would make the infrastructure that distributes binaries to
>> all our users susceptible to malicious PRs.
> How is reviewing a PR, then letting it build and, if it succeeds, uploading
> the binary,
We don't want PR builds to upload any binaries anywhere. PRs are unapproved.
Only after a PR has been approved and merged to master should a binary be
uploaded anywhere. And that's what our buildbot currently does -- it gets
notified of the commit to master and does the build.
> if not, reporting the results — different from the current setup, which it
> seems to me duplicates the process, instead of reusing the infrastructure?
> If a PR fails for all or some systems, then the changes would never make it
> into the tree, respectively, sparing trac.
> I'd like to understand what is current and what would be the ideal CI for MP
> and what's needed to get there.
When a change is committed, our buildbot system builds the change. If the
change relates to ports, it mirrors the distfiles, builds the changed ports
using mpbb and uploads the binaries, and regenerates the SQL database that
powers ports.php on our web site. If the change relates to base, it builds
base, and renders the manpages to HTML and uploads them to the web server. If
the change relates to the web site, it validates the files and uploads them to
the web server. If the change relates to the guide, it regenerates the guide
HTML and uploads it to the web server. Our buildbot system was originally set
up in 2011 by macOS forge, and was rebuilt and redesigned when we moved it onto
my hardware in late 2016.
When a PR for ports is submitted, Travis CI goes to work building the port
using mpbb, and runs port lint, and reports on the lint and build results in
the PR. This was set up some time after MacPorts moved to GitHub in late 2016.
Travis is a free service for open-source projects. They provide the hardware
and the software running on it, and control the ways in which it can be
customized, and impose limitations on its use. I was not involved in getting
Travis up and running for MacPorts. Travis was selected, rather than reusing
any of our existing buildbot infrastructure, presumably because the steps
required to accomplish the task on buildbot were unclear or thought to be
complicated or time-consuming.
Different developers may have different ideas of what's ideal. Some may wish to
keep Travis CI for testing PRs, and just try to incrementally improve it,
reduce differences between its behavior and buildbot's, etc. Others may wish to
replace it with something that runs on buildbot, so that we can control it
completely and aren't subject to the whims and restrictions of the Travis
service. I believe I would prefer something running on buildbot, because I
dislike having two different systems that behave differently.