936330 - Allow try builds to end prematurely and be marked as successful

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect)

Description

[Mike Hommey [:glandium]]

Countless times to test some build changes across all platforms, I've used try, but both didn't want to wait for an entire build to end and to waste infrastructure resources.

So what I've been doing in these cases is to voluntarily end the build prematurely at some point that makes sense by making a change to what i push that does that (like, when testing configure stuff, adding exit 1 at the end of configure.in). The problem is that the try results are red and i need to parse the build logs to see if what i expected happened or not.

It would be super useful if it was possible to have a way to end the build prematurely with a green status. For example, if when a build step fails but there is a STOP_OK file at the top of the objdir, don't do the next steps and mark the build green.

Comment 1

[Ed Morley [:emorley]]

buildbotcustom has a tangled web of logic determining the status of a run (the location of which varies depending on desktop vs mobile, builds vs unit tests vs talos etc), however in general it's a combination of exit code and/or log parsing with a bunch of flags used to determine if buildbot aborts the run immediately after that buildbot step, ignores it entirely etc.

I imagine the easiest way to solve this would be:
* See if exit code is used for builds (and whether we parse the logs as well) - if just exit code, then that's easy to fix via the method you already use.
* Failing that: add a custom string to the logic just for builds, which if present in stdout, overrides the status for that run.

Comment 2

[Mike Hommey [:glandium]]

So, one thing I've just done now is to print "TinderboxPrint: something" before prematurely exiting, which is already more convenient than opening logs and looking at them. Maybe a special TinderboxPrint line triggering the status to be green would be enough. If I'm not mistaken, that could probably be done on tbpl's end.

Comment 3

[Ed Morley [:emorley]]

TBPL cannot change the result (or more it doesn't currently and it isn't desirable to start doing so) of completed jobs.

You can of course tinderbox print a "yeah this has finished fine, ignore the red" message, to avoid you having to open the full log, but the run is still going to show as red, unless the buildbotcustom logic is changed.

Comment 4

[Chris AtLee [:catlee]]

I think an 'exit 0' should work in Taskcluster?