526495 - Support for special tag in commit message that will prevent builds from being triggered

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P5)

Description

[Chris AtLee [:catlee]]

There are some cases where we don't want to trigger a build on a checkin.

If a commit message contains the string "DONTBUILD", for example, we could skip triggering a build.  buildbot's fileIsImportant function may be able to do this, or it could be done in the hg poller.

Comment 1

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

What sort of use cases are left for this now that bug 466931 is resolved ?

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

eg comment/whitespace fixes were builds are a waste of CPU. Relevant code is at 
  http://hg.mozilla.org/build/buildbotcustom/file/default/misc.py#l94

Comment 4

[Chris AtLee [:catlee]]

http://hg.mozilla.org/build/buildbotcustom/file/buildbot-0.8.0/misc.py#l108

Comment 5

[Chris AtLee [:catlee]]

Attachment: Don't trigger builds when comments contain DONTBUILD

Needs testing, but I think this should work

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 489036 [details] [diff] [review]
Don't trigger builds when comments contain DONTBUILD

Looks likely to work.

Comment 7

[Chris AtLee [:catlee]]

Local tests work.  This just needs a reconfig on the main scheduler master.

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

Credit where is credit is due, over to catlee.

Comment 9

[Chris AtLee [:catlee]]

Comment on attachment 489036 [details] [diff] [review]
Don't trigger builds when comments contain DONTBUILD

changeset:   1112:73d884fd7472

Comment 10

[Reed Loden [:reed]]

(In reply to comment #3)
> eg comment/whitespace fixes were builds are a waste of CPU. Relevant code is at 
>   http://hg.mozilla.org/build/buildbotcustom/file/default/misc.py#l94

I'd say most of the time we do comment/whitespace fixes it's *because* we want builds.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to comment #10)
> I'd say most of the time we do comment/whitespace fixes it's *because* we want
> builds.

So?  When that's the case, the pusher clearly doesn't want to make use of this new keyword. :)

I think this is more for cases like "Oops, the patch I just pushed had a typo in its comment. Let me fix that in a quick followup [without triggering >100 more CPU-hours of builds/unittests]"

Comment 12

[Nochum Sossonko [:Natch]]

Does this work for multiple changesets the same way CLOSED TREE does? I.e., if there are multiple changesets and one contains the work DONTBUILD, is is supposed to build or not?

Comment 13

[Chris AtLee [:catlee]]

(In reply to comment #12)
> Does this work for multiple changesets the same way CLOSED TREE does? I.e., if
> there are multiple changesets and one contains the work DONTBUILD, is is
> supposed to build or not?

Any new cset that doesn't have DONTBUILD will trigger a build.

Comment 14

[Daniel Holbert [:dholbert]]

To be a little more specific: if a push has any normal (non-DONTBUILD) changesets, then it will get a build, and that build will be triggered for the latest changeset in the push, even if that latest changeset had DONTBUILD in its commit message.

(I just verified the above with this mixed normal/DONTBUILD push:
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=f4fc9593ca7d )

Comment 15

[Axel Hecht [:Pike]]

tbpl reports builds for http://hg.mozilla.org/mozilla-central/rev/4273e6a3cd49.

Comment 16

[Daniel Holbert [:dholbert]]

just to save duplicate work: http://build.mozilla.org/builds/running.html agrees with comment 15 -- it shows builds running for Axel's "DONTBUILD" cset, 4273e6a3cd49.

That problem probably wants a followup bug, though, right?  I've confirmed that DONTBUILD does *sometimes* work (or at least did last Friday), so I think reopening this bug here would be overkill.

Comment 17

[Chris AtLee [:catlee]]

These are all instances of bug 613429.

Once the builds are finished they'll show up in the right place.

Comment 18

[Axel Hecht [:Pike]]

http://tbpl.mozilla.org/?tree=Mobile actually shows completed builds for that sourcestamp.

Comment 19

[Chris AtLee [:catlee]]

(In reply to comment #18)
> http://tbpl.mozilla.org/?tree=Mobile actually shows completed builds for that
> sourcestamp.

Ok, that's a real bug :)

Comment 20

[Chris AtLee [:catlee]]

(In reply to comment #19)
> (In reply to comment #18)
> > http://tbpl.mozilla.org/?tree=Mobile actually shows completed builds for that
> > sourcestamp.
> 
> Ok, that's a real bug :)

...which I'm tempted to leave for now.  The mobile stuff is still on older systems, which don't get change comments directly.

Comment 21

[Chris AtLee [:catlee]]

The mobile code is being ported forward to 0.8, at which point it will inherit this behaviour.

If it's urgent that we support this now for mobile, let's open another bug.

Comment 22

[Nochum Sossonko [:Natch]]

Builds were run for commit http://hg.mozilla.org/mozilla-central/rev/0474f6b72e6e which specified DONTBUILD. Strange...

Comment 23

[Chris AtLee [:catlee]]

(In reply to comment #22)
> Builds were run for commit
> http://hg.mozilla.org/mozilla-central/rev/0474f6b72e6e which specified
> DONTBUILD. Strange...

The linux nightly build was manually triggered.