Closed Bug 426214 Opened 13 years ago Closed 10 years ago

Automatically update blocklist.xml in cvs/hg from blocklist service

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mossop, Assigned: coop)

References

Details

Attachments

(6 files, 6 obsolete files)

1.49 KB, text/plain
bhearsum
: review+
Details
800 bytes, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
4.16 KB, text/plain
coop
: review+
Details
7.49 KB, patch
armenzg
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
6.11 KB, patch
armenzg
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
3.93 KB, patch
bhearsum
: review+
Details | Diff | Splinter Review
Now that the blocklsit is being shipped with builds we should automatically update the version in CVS periodically so we are shipping a recent copy. Apparently this can be done similarly to how autoconf is run on configure.in.

The blocklist file in cvs is at browser/app/blocklist.xml.
The latest blocklist can always be pulled from https://addons.mozilla.org/blocklist/1/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/3.0/ (the actual version string shouldn't matter but a version is necessary.

The file is not updated that frequently but I guess at least a daily check would be sensible.
Priority: -- → P3
A downside of this method is that it won't pay any attention to the current tree state, bypassing any requirements for approval. configure is different because the configure.in checkin still requires that.
So as I see it there are two potential issues with this.

The first is that the tree may be burning or closed when the blocklist is updated. A check in at this point might be considered a bad thing. This could be avoided by using quickparse to determine the tree state, but I'm not sure whether it is necessary. The blocklist file shouldn't impact the success of builds.

The second is that the tree state may mean that check ins require specific approvals. I would suggest that the process that is gone through to update the remote blocklist itself could be taken as being approval to land the update in tree.

Thoughts?
I agree that neither of those issues are practically significant enough to prevent us from doing this.  cltbld's update of configure can happen on a suddenly-red tree, too, and we are not especially concerned about it either.

*My* only concern is that if something's wrong with the tree (maint window, network problem, etc.) then an update may not be successful, in which case we have an out-of-sync in-tree blocklist.  To remedy that, I propose a nagios check of bonsai against the remote database, with ~30 mins wiggle room for bonsai's mirror propagation.
This is based on sync-configure but with the branch support ripped out (since we'll no doubt be using Hg for 3.next and will need lots of changes here). TDIR is modified from sync-configure.

Anyone want to pick holes in it ?
Assignee: nobody → sachinrthomas
Priority: P3 → P2
Assignee: sachinrthomas → nthomas
Comment on attachment 320184 [details]
[checked in] sync-blocklist v1

How does this look to you ? You can look at egg:~/bin/sync-configure for the original script.
Attachment #320184 - Flags: review?(bhearsum)
Comment on attachment 320184 [details]
[checked in] sync-blocklist v1

Seems fine
Attachment #320184 - Flags: review?(bhearsum) → review+
Comment on attachment 320184 [details]
[checked in] sync-blocklist v1

RCS file: /cvsroot/mozilla/tools/build/sync-blocklist,v
done
Checking in sync-blocklist;
/cvsroot/mozilla/tools/build/sync-blocklist,v  <--  sync-blocklist
initial revision: 1.1
done
Attachment #320184 - Attachment description: sync-blocklist v1 → [checked in] sync-blocklist v1
Depends on: 442250
Ok, this is live on egg and it committed a catchup immediately:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/app&command=DIFF_FRAMESET&file=blocklist.xml&rev1=1.2&rev2=1.3&root=/cvsroot

I'm guessing we'll want to do this for mozilla-central too so leaving this open for someone to take.
Assignee: nthomas → nobody
Priority: P2 → P3
Whiteboard: live on cvs trunk, want mozilla-central version too ?
Attached file sync-hg-blocklist (obsolete) —
This is a way of doing the same thing for mozilla-central. The process is pretty much the same, check out the tree, download the blocklist, if they are different commit the change and push it. If someone else lands a changeset between the time the tree is cloned and the attempt to push then the push will simply fail and the change will be attempted again next time around.

This is probably not all that ideal however. It is very slow for me since it starts from scratch each time and clones the entire tree. Maybe this is actually fast enough on the machine the script runs from?

Other option is to keep a full clone, just pull updates each time and if the push of the changed blocklist fails then just rollback the commit and try again next time.
Attachment #327255 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 327255 [details]
sync-hg-blocklist

>#!/bin/sh -x
>
># 2008-06-27 - Copied from sync-blocklist (dtownsend)
>
>HGPUSHREPO='ssh://hg.mozilla.org/mozilla/central/'

Fix the typo here.

>
>HG=hg

This is going to be /usr/local/bin/hg when it runs on egg, no need to change it here though, I guess.

>WGET=wget
>DIFF=diff
>PATH="/usr/bin:/bin:/usr/local/bin:/usr/sbin:/usr/bsd:/sbin:/usr/bin:/bin:/usr/etc:/usr/ucb"
>TDIR="/tmp/b-s.$$"

I like your idea of maintaining an m-c clone, let's make this something permanent. On egg, it will probably be /builds/cltbld/mozilla-central-blocklist.

>HOST=`/bin/hostname -f`
>export PATH
>
>rm -rf ${TDIR}
>mkdir ${TDIR}
>cd ${TDIR}
>

Since we're not deleting and re-cloning each time check for existence here, and create the directory if it doesn't exist.

>use_tmpdir() 
>{
>    ${HG} clone $HGREPO mozilla

I guess you need to test for a valid repo and clone or 'pull -u' depending on the case.

>    CLONE_STATUS=$?
>    if [ $CLONE_STATUS != 0 ]
>    then
>        echo "ERROR hg clone exited with a non-zero exit code: $CLONE_STATUS"
>        return $CLONE_STATUS
>    fi
>
>    ${WGET} --no-check-certificate -O blocklist.xml ${URL}
>    WGET_STATUS=$?
>    if [ $WGET_STATUS != 0 ]
>    then
>        echo "ERROR wget exited with a non-zero exit code: $WGET_STATUS"
>        return $WGET_STATUS
>    fi
>    
>    ${DIFF} blocklist.xml mozilla/browser/app/blocklist.xml >/dev/null 2>&1
>    DIFF_STATUS=$?
>    if [ $DIFF_STATUS == 1 ]
>    then
>        cp -f blocklist.xml mozilla/browser/app/blocklist.xml
>        cd mozilla
>        ${HG} commit -m "Automated update from host $HOST"
>        ${HG} push ${HGPUSHREPO}
>        PUSH_STATUS=$?
>        if [ $PUSH_STATUS != 0 ]
>        then
>            echo "ERROR hg push exited with exit code: $PUSH_STATUS"
>            return $PUSH_STATUS
>        fi

I'm not sure this script will recover as well if we're maintaining a clone. Can you make sure you handle the case where you need a merge commit before pushing? It *might* do it properly on the next run, but I'm not sure. I'll leave that testing up to you ;-).

>    elif [ $DIFF_STATUS == 0 ]
>    then
>        return 0
>    else 
>        echo "ERROR diff exited with exit code: $DIFF_STATUS"
>        return $DIFF_STATUS
>    fi
>}
>
>use_tmpdir
>result=$?
>rm -rf ${TDIR}

Remove this, of course :).

>exit $result
Attachment #327255 - Flags: review-
Attached file sync-hg-blocklist v2 (obsolete) —
This updates to use a local clone that sticks around between runs. If the clone is not present it is created. The chances of racing a checkin are vastly reduced by downloading the new blocklist then updating, then checking and committing. If the push fails however the local commit is rolled back so that it will attempt again the next time around. If rolling back fails (I don't know what could cause this other than a mercurial error) then I opted to just wipe the local clone so it will start complete fresh next time.

I tested this out with a clone of mozilla-central and it works fine. By adding in a sleep statement I also raced a checkin with it and it correctly handled it.

Example changeset:
http://hg.oxymoronical.com/hgwebdir.cgi/mozilla/central-clone/rev/d4bb1644d6aa
Attachment #327255 - Attachment is obsolete: true
Attachment #329550 - Flags: review?(bhearsum)
Assigning to Dave for now, send it back to us when you have review.
Assignee: nobody → dtownsend
Attachment #329550 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 329550 [details]
sync-hg-blocklist v2

>#!/bin/sh -x
>
>HGUSER='cltbld <cltbld@mozilla.org>'

We're moving away from 'cltbld' as a username on hg, stage, etc. We won't have a cltbld account on hg.m.o, switch this to 'ffxbld'.

Everything else here looks fine.
Attachment #329550 - Flags: review?(bhearsum) → review+
Attached file sync-hg-blocklist v3 (obsolete) —
Comment addressed
Attachment #329550 - Attachment is obsolete: true
Over to you Nick?
Assignee: dtownsend → sachinrthomas
Assignee: sachinrthomas → nthomas
Whiteboard: live on cvs trunk, want mozilla-central version too ? → [checkin to hg.m.o/build/tools]
Some notes/queries:

* John suggested running the mercurial version of this as a builder on a buildbot master, rather than put more stuff onto onto egg. So we'd pull from hg.m.o/build/tools/ and run blocklist/sync-hg-blocklist, probably using the pool of linux slaves. What do you think Ben ? Obviously requires another 560 MB (and counting) hunk of disk but gives us more fault tolerance. Dunno if the moz2 buildbot makes sense, or if we should setup a new "services" one, with a couple of linux slaves from moz2 connected. Don't particularly want a bunch of ancillary jobs polluting the moz2 buildbot waterfall. Does that location in the repo sound ok ? 

* We're blocked by bug 447666 for hg push access

* Should we be updating the URL for bug 430120 for both hg and cvs scripts to the 2nd schema ? Should the mercurial version at least be setting a version of 3.1 ?
Depends on: 447666
I think running it from a Buildbot is a great idea. We can probably run it *only* when configure.in checks in, too, rather than every 5 minutes, or whatever. I also think it makes sense to start a "services" buildbot, with a separate set of one or two Linux slaves, or w/e.
(In reply to comment #17)
> I think running it from a Buildbot is a great idea. We can probably run it
> *only* when configure.in checks in, too, rather than every 5 minutes, or
> whatever. I also think it makes sense to start a "services" buildbot, with a
> separate set of one or two Linux slaves, or w/e.

This isn't the configure generation script ;)

Otherwise yes seems like a sensible idea to me.
Er, right :). /me shakes his head
Summary: Automatically update blocklist.xml in cvs from blocklist service → Automatically update blocklist.xml in cvs/hg from blocklist service
(In reply to comment #17)
> I think running it from a Buildbot is a great idea. We can probably run it
> *only* when configure.in checks in, too, rather than every 5 minutes, or
> whatever. I also think it makes sense to start a "services" buildbot, with a
> separate set of one or two Linux slaves, or w/e.
> 

Just to be clear, I think we should integrate these at some point. I have ideas about how to do this but there are much more pressing concerns at this point. The shortest path to win here is setting up a new Buildbot for this.
(In reply to comment #16)
> * Should we be updating the URL for bug 430120 for both hg and cvs scripts to
> the 2nd schema ? Should the mercurial version at least be setting a version of
> 3.1 ?

We probably should for consistency I guess, on the off chance something changes and breaks the old schema. Though that does require us to make up sensible defaults for the OS fields and such.
We need to update the url used to retrieve the blocklist for CVS. The new URL should be:

https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0/Firefox/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/

This should cause an immediate update of the blocklist file in CVS with new data.
Got a rubber stamp in your arsenal ?
Attachment #355697 - Flags: review?(bhearsum)
Attachment #355697 - Attachment description: Update URL → Update URL for CVS/fx3.0 version
Comment on attachment 355697 [details] [diff] [review]
Update URL for CVS/fx3.0 version

Welcome to stampytown.
Attachment #355697 - Flags: review?(bhearsum) → review+
Attachment #355697 - Flags: checked‑in+
Comment on attachment 355697 [details] [diff] [review]
Update URL for CVS/fx3.0 version

Checking in sync-blocklist;
/cvsroot/mozilla/tools/build/sync-blocklist,v  <--  sync-blocklist
new revision: 1.4; previous revision: 1.3
done

And the script updated on egg. The change Mossop predicted is 
  http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/app&command=DIFF_FRAMESET&file=blocklist.xml&rev1=1.14&rev2=1.15&root=/cvsroot
(In reply to comment #25)
> (From update of attachment 355697 [details] [diff] [review])
> Checking in sync-blocklist;
> /cvsroot/mozilla/tools/build/sync-blocklist,v  <--  sync-blocklist
> new revision: 1.4; previous revision: 1.3
> done
> 
> And the script updated on egg. The change Mossop predicted is 
>  
> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/app&command=DIFF_FRAMESET&file=blocklist.xml&rev1=1.14&rev2=1.15&root=/cvsroot

Looks perfect, thanks
Assignee: nrthomas → nobody
Priority: P3 → P5
Is this still required? How have we been handling blocklist updates in the intervening 17 months?
Assignee: nobody → ccooper
Priority: P5 → P3
(In reply to comment #27)
> Is this still required?

Yes

> How have we been handling blocklist updates in the intervening 17 months?

Badly. In theory someone (in the past me but I have not had chance for some time) creates a patch containing the blocklist changes and gets the approvals to land them in the tree.
(In reply to comment #28)
> Badly. In theory someone (in the past me but I have not had chance for some
> time) creates a patch containing the blocklist changes and gets the approvals
> to land them in the tree.

Would a weekly scheduled build do the job here? We could schedule it for the weekend when things are relatively quiet, and then we could trigger it manually whenever we wanted as well.
(In reply to comment #29)
> (In reply to comment #28)
> > Badly. In theory someone (in the past me but I have not had chance for some
> > time) creates a patch containing the blocklist changes and gets the approvals
> > to land them in the tree.
> 
> Would a weekly scheduled build do the job here? We could schedule it for the
> weekend when things are relatively quiet, and then we could trigger it manually
> whenever we wanted as well.

Sounds fine to me. The main goal is to make sure that whenever we do a release the shipped blocklist is as up to date as possible.
Status: NEW → ASSIGNED
Priority: P3 → P2
Here's what I've chosen to do: take Mossop's most recent hg-based script (sync-hg-blocklist v3) and modify so that we download and compare the blocklist file from AMO and hg *before* we worry about any cloning. In the likely scenario that there is no update to the blocklist, we don't clone unnecessarily, avoiding increased disk usage on some random slave and returning much more quickly.
Attached file sync-hg-blocklist v4 (obsolete) —
Changes from v3:

* requires a branch on the command line so we can update the blocklist.xml for any/all branches
* separated out the diffing and updating logic so we can have a dry-run mode
* compares the current AMO blocklist with the single file retrieved from hgweb before trying to do any cloning

This script should live under hg.m.o/build/tools, but not sure exactly where. Possibly build/tools/scripts.

I'll wrap this in a builder next week.
Attachment #331111 - Attachment is obsolete: true
Attachment #474294 - Flags: review?
Whiteboard: [checkin to hg.m.o/build/tools]
Comment on attachment 474294 [details]
sync-hg-blocklist v4

Should add that I was able to update the blocklist in my own sparse repo using this script:

http://hg.mozilla.org/users/coop_mozilla.com/blocklist-update
Attachment #474294 - Flags: review? → review?(nrthomas)
Comment on attachment 474294 [details]
sync-hg-blocklist v4

>BLOCKLIST_URL_AMO='https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0/Firefox/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/'

Mossop, is it safe to request blocklist as Firefox 3.0 then landing in 3.5, 3.6 and 4.0 repos ? Do we ever block things for specific 3.6.x versions ? Perhaps we should be requesting using the current version from hg's copy of version.txt, and putting it in the blocklist URL.

>REPODIR='mozilla-central-blocklist'

enh: choose something branch agnostic.

>    if [ $WGET_STATUS != 0 ]; then
>        echo "ERROR wget exited with a non-zero exit code: $WGET_STATUS"

enh: say what each of these calls was trying to do in the error message. Or do we get all the stdout/stderr anyway ?

>    ${WGET} -O blocklist_hg.xml ${BLOCKLIST_URL_HG}

enh: might want to set a timeout on the wget operations. Looks like the default is 15 mins waiting to read data, and nothing on connection. Can't set a buildbot timeout too short or cloning might get cut off.

>    ${DIFF} blocklist_hg.xml blocklist_amo.xml >/dev/null 2>&1

Is the ordering of AMO's response fixed ? Will this diff flap a lot ?

>    ${HG} -R $REPODIR update -C default

Nice.

>    PUSH_STATUS=$?
>    PUSH_STATUS=0

Fix: Typo left over from testing ?

>    if [ $PUSH_STATUS != 0 ]; then
[snip rollback stuff]
>        return $PUSH_STATUS

Fix: Should do this outside the if block, to handle the push working.

r+ with two fixes and Mossop is happy with the URL and potential flap; enhancements at your discretion.
Attachment #474294 - Flags: review?(nrthomas)
Attachment #474294 - Flags: review?(dtownsend)
Attachment #474294 - Flags: review+
(In reply to comment #34)
> Comment on attachment 474294 [details]
> sync-hg-blocklist v4
> 
> >BLOCKLIST_URL_AMO='https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0/Firefox/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/'
> 
> Mossop, is it safe to request blocklist as Firefox 3.0 then landing in 3.5, 3.6
> and 4.0 repos ? Do we ever block things for specific 3.6.x versions ? Perhaps
> we should be requesting using the current version from hg's copy of
> version.txt, and putting it in the blocklist URL.

As it stands I don't think the blocklist script outputs anything different for different appversions so long as the schema number is the same, morgamic could verify that.

However were I a betting man I'd guess that that situation might arise and if it isn't too much hassle then getting the actual version would be safer in the long run.
Comment on attachment 474294 [details]
sync-hg-blocklist v4

Mike, can you confirm/refute comment 35, otherwise this looks great to me.
Attachment #474294 - Flags: review?(dtownsend) → review?(morgamic)
(In reply to comment #35)
> However were I a betting man I'd guess that that situation might arise and if
> it isn't too much hassle then getting the actual version would be safer in the
> long run.

If I am grabbing the version from version.txt, should I be stripping out any extraneous version info, i.e. 4.0b7pre would become 4.0?
(In reply to comment #37)
> (In reply to comment #35)
> > However were I a betting man I'd guess that that situation might arise and if
> > it isn't too much hassle then getting the actual version would be safer in the
> > long run.
> 
> If I am grabbing the version from version.txt, should I be stripping out any
> extraneous version info, i.e. 4.0b7pre would become 4.0?

I might say strip off the "pre" since what you're checking in to that tree would then ship in b7, but I don't think it is a big deal at that point.
Attached patch sync-hg-blocklist v5 (obsolete) — Splinter Review
(In reply to comment #34)
> enh: say what each of these calls was trying to do in the error message. Or do
> we get all the stdout/stderr anyway ?

We get all the wget output, so that should be sufficient to diagnose failures. Fixed all other nits.

This new patch uses the version retrieved from version.txt to create the blocklist URL. Carrying forward review from nthomas based on comment #34, but still want morgamic's input based on comment #36.
Attachment #474294 - Attachment is obsolete: true
Attachment #477017 - Flags: review+
Attachment #477017 - Flags: feedback?(morgamic)
Attachment #474294 - Flags: review?(morgamic)
Attached file sync-hg-blocklist v5
And this time without the testing shims. Ahem.
Attachment #477017 - Attachment is obsolete: true
Attachment #477114 - Flags: review+
Attachment #477114 - Flags: feedback?(morgamic)
Attachment #477017 - Flags: feedback?(morgamic)
morgamic: gentle ping re: feedback/comment #36
Attachment #477114 - Flags: feedback?(morgamic)
ScriptFactory makes this really straightforward. I've used this patch to update the blocklist a few times in staging.
Attachment #489944 - Flags: review?(armenzg)
Pretty straightforward. I enable blocklist updating for m-c, 1.9.2, and 1.9.2. If you don't think we should be doing blocklist_update_on_closed_tree, we can turn that off on landing.

I turn off the blocklist updater in staging so that we don't accidentally update a production repo from staging. I used the stage-ffxbld user repo for my testing in staging.

I've added a blocklist stanza for mozilla-2.0 which is currently off by default with the thought that we'll want to turn it on once that branch is cut (again).
Attachment #489948 - Flags: review?(armenzg)
Comment on attachment 489944 [details] [diff] [review]
Use ScriptFactory to run the blocklist update script

If it aids review at all, the added code is simply duplicated in generateBranchObjects/generateCCBranchObjects on the assumption that they will want this too.

I've set this up to run weekly, just like the code coverage builder.
Comment on attachment 489948 [details] [diff] [review]
Config changes needed to run the blocklist script

Looks good.

Why you don't specify a "hg_ssh_key" for staging? Not necessary?
Attachment #489948 - Flags: review?(armenzg) → review+
Comment on attachment 489944 [details] [diff] [review]
Use ScriptFactory to run the blocklist update script

It looks good but I would like you to tuck it in a function like generateFuzzingObjects and generateNanojitObjects for consistency in style.
Also to be called from generateProjectObjects.
Attachment #489944 - Flags: review?(armenzg) → review-
(In reply to comment #47)
> It looks good but I would like you to tuck it in a function like
> generateFuzzingObjects and generateNanojitObjects for consistency in style.
> Also to be called from generateProjectObjects.

It's not a project though, it's more akin to code coverage in that it's a single platform builder that we'd like to run on a weekly basis.

Still, you raise a valid point. Since the code is going to be used in two spots (core and CC), I've move the factory/builder generation into a function so we don't have to update it in two spots.

Tested again in staging and it still works with the existing config change patch.
Attachment #489944 - Attachment is obsolete: true
Attachment #492728 - Flags: review?(armenzg)
Comment on attachment 492728 [details] [diff] [review]
Use ScriptFactory to run the blocklist update script, v2

I agree with your arguments.

Please notify CC of the new parameter or use config.get("enable_blocklist_update",False) so it won't bite them.

r+ with that.
Attachment #492728 - Flags: review?(armenzg) → review+
(In reply to comment #49) 
> Please notify CC of the new parameter or use
> config.get("enable_blocklist_update",False) so it won't bite them.

I'll get a patch landed with that change today in prep for the downtime tomorrow.
Patch is ready to land for the downtime.
Flags: needs-reconfig?
Flags: needs-reconfig? → needs-reconfig+
Comment on attachment 489948 [details] [diff] [review]
Config changes needed to run the blocklist script

changeset:   3373:cdd56ea6b09b
Attachment #489948 - Flags: checked-in+
Comment on attachment 492728 [details] [diff] [review]
Use ScriptFactory to run the blocklist update script, v2

changeset:   1215:06e8f018bf17
Attachment #492728 - Flags: checked-in+
Looks like there's nothing left to do here.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
This caused orange, almost certainly due to a test making bad assumptions. We had to back it out to get the tree green.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
backed out in changeset:   1216:ae9ce9a45535
currently updating the buildbot masters
(In reply to comment #57)
> backed out in changeset:   1216:ae9ce9a45535
> currently updating the buildbot masters

scratch that, turned off in changeset:   changeset:   3376:2af03a3117de of buildbot-configs
I filed bug 614868 describing what's wrong with the test.
Depends on: 614868
Removing old needs-reconfig+ flag
Flags: needs-reconfig+
Attachment #495055 - Flags: review?(bhearsum) → review+
Comment on attachment 495055 [details] [diff] [review]
Turn blocklist updating back on for m-c, 1.9.2, and 1.9.1

https://hg.mozilla.org/build/buildbot-configs/rev/e2cf5d5ad955
Attachment #495055 - Flags: checked-in+
Builder masters reconfig-ed with blocklisting enabled.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
(In reply to comment #63)
> Builder masters reconfig-ed with blocklisting enabled.

Doesn't look like the blocklist changes got checked in, are we waiting on a downtime to turn this on or something?
(In reply to comment #64)
> Doesn't look like the blocklist changes got checked in, are we waiting on a
> downtime to turn this on or something?

No, the builder hasn't run again since being updated earlier in the week. It's only scheduled to run weekly (on Saturdays, IIRC).

I've triggered the builder by hand. It looks like mozilla-central is the only branch that needs updating at present.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.