On 25 October 2017 at 18:09, Craig Treleaven wrote: > > If we’re going to do this, can we be a little more precise about “failed” > builds?
Not yet at this stage unless/until someone comes up and implements the needed functionality in the core. (Like Ryan said.) Ideally the buildbot would not even attempt to build a port that's not compatible, so we wouldn't even get any failure reports. We might still want to record "skipped" or something similar in that case, but that's a different / parallel problem. > 1) Any port that relies on a non-default variant “fails” on the buildbots. > All of my myth* ports will ALWAYS show a “failed” status on ALL of the > buildbots for this reason. I would rather that users were told that the > build was “not attempted”. Telling them that build “failed" isn’t helpful. That's yet another problem that could be fixed in a different way, probably once the dependency engine implementation (a past GSOC project) gets deployed. Once we fix this properly, it should no longer be an issue. > 2) Any port that needs C++11 “fails” on the existing 10.7 and earlier > buildbots. That's not entirely true. The cxx11 1.1 portgroup often works fine. But I would not worry about this case for now. We are not attempting to go for 100% success rate, just collect statistics for now. > 3) Various ports have a pre-fetch block that checks the OS version and > “fails” if it is not supported. See the first point above. > Assuming the above can be fixed, Independent of this ... > is the following a mock-up of the data we’d collect? Each commit to the > ports tree triggers builds on the then-current fleet of builders: > > Port: blurfl > Verson: 2.54.1_0 > Commmit: > https://github.com/macports/macports-ports/commit/6b120d678245ba6f14a5a364f83c3c5970f762af > > Buildbots: > Builder Build ID Build (minutes.seconds) > X86-10.13 nnnnnnnn 1.20 > X86-10.12 nnnnnnnn 2.20 > X86-10.11 nnnnnnnn 2.00 > X86-10.10 nnnnnnnn 4.50 > X86-10.9 nnnnnnnn 2.40 > X86-10.8 nnnnnnnn fail > X86-10.7 nnnnnnnn not supported > X86-10.6 nnnnnnnn not supported > PPC-10.5 nnnnnnnn not supported Yes, something in that sense. For now we would not have the "not supported" flag until the core functionality changes. For the failed case it would be helpful to know whether any earlier version successfully built. And some builders might not have the latest version built yet (probably still waiting somewhere in the queue). I would probably collect some more simple parameters, but success/failure/version is the most important one anyway. Mojca
