Checking for problems before committing

[Mojca Miklavec]

(Was: Why do so many builds fail? @ macports-users)

On 10 March 2016 at 05:48, Ryan Schmidt wrote:
>
> Obviously nobody is going to commit something they believe is broken, but it does sometimes end up being the case for some subset of users. When it does, and we learn that it has happened, we try to fix it. If everybody had to test everything on a clean system on every version of OS X and every version of Xcode before committing, nobody would ever commit anything because nobody has the time and resources to do all that testing. We do have automated build machines that do build every commit on a clean system with no ports installed with several versions of OS X and the latest version of Xcode for those systems. That automated system did catch this webkit2-gtk build problem on El Capitan,


When I was testing wxWidgets, discovered a problem and submitted a
patch, I noticed what they are doing now (which is some light years
more advanced compared to what they did a few years back when most of
the tickets were stuck ignored at their Trac; similar to what happens
in many cases in MacPorts).

- user submits a patch
- the system checks whether the patch applies cleanly
- the system automatically builds wxWidgets on Windows in 6 different
ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
VS 9, msbuild), on Linux in five different ways (one is with clang
3.5), and on OS X 10.9
- I'm not sure whether wxWidgets does it as well, but it is also
possible to run tests as part of the build

The developers then only apply the patch if all of the checks mentioned pass.

The point is that this is all done *in advance* and avoids a lot of
problems. I would love to see something similar being done for patches
submitted to our Trac. Of course they would have to be submitted in a
different way and I'm aware that this is not really trivial to set up.
But it would be extremely helpful.

Mojca