add ACL-setting code to upload_rendered_skps.py

add ACL-setting code to upload_rendered_skps.py

BUG=skia:1942
Committed: https://skia.googlesource.com/buildbot/+/68c4f171aa73f1164ed88ea204b23e1f1a3e2e94

[epoger, 2014-07-18 21:10:25]

PTAL at patchset 2.

Guys, if you could please *both* take a look I would appreciate it.  It's short.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/build_step.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:62: BUILDBOT_PATH, 'third_party',
'chromium_buildbot', 'site_config', '.boto')
This is where we already put the .boto file on the bots... we can change this
path if we want, once old_gs_utils.py is gone.  (Unless we need the
chromium_buildbot code to use these same credentials???)

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:35: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
Actually, I guess now (before we start uploading these rendered SKP images) is a
good time to ask: Should we create a new bucket specifically for them, rather
than uploading them into gs://chromium-skia-gm/rendered-skps ?

I think a separate bucket is better.  (It allows us to set bucket
permissions/configs that are appropriate for each use.)  What do you think?

Shall I ask to have a new "chromium-skia-skp-images" bucket created for this
purpose?  (Consistent with the "'chromium-skia-skp-summaries" bucket we had
created for the summary files.)

[epoger, 2014-07-18 21:15:07]

I forgot to mention: You can check out the files (and permissions) of the files
I uploaded in test:


SUMMARY FILE:

epoger@wpgntat-ubiq141:~$ gsutil ls -L -r
gs://chromium-skia-skp-summaries/Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug
gs://chromium-skia-skp-summaries/Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug/:
gs://chromium-skia-skp-summaries/Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug/renderskp-defaults.json:
	Creation time:		Fri, 18 Jul 2014 20:07:49 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		2388460
	Content-Type:		application/json
	Hash (crc32c):		c4b7fd80
	Hash (md5):		a7d68f10a3ae4081cf7243b9236566ac
	ETag:			a7d68f10a3ae4081cf7243b9236566ac
	Generation:		1405714069784000
	Metageneration:		1
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>>
TOTAL: 1 objects, 2388460 bytes (2.28 MB)


IMAGE FILES:

epoger@wpgntat-ubiq141:~$ gsutil ls -L -r gs://chromium-skia-gm/rendered-skps
gs://chromium-skia-gm/rendered-skps/:

gs://chromium-skia-gm/rendered-skps/desk_amazon_skp/:
gs://chromium-skia-gm/rendered-skps/desk_amazon_skp/bitmap-64bitMD5_2093942069890468477.png:
	Creation time:		Fri, 18 Jul 2014 20:51:24 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		16190
	Content-Type:		image/png
	Hash (crc32c):		d4ce9d27
	Hash (md5):		34e4cc43c025e2ee9f79e0959d66b75d
	ETag:			34e4cc43c025e2ee9f79e0959d66b75d
	Generation:		1405716684386000
	Metageneration:		2
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>, <<GroupByDomain: google.com>: u'READ'>>
gs://chromium-skia-gm/rendered-skps/desk_amazon_skp/bitmap-64bitMD5_2793756673679144888.png:
	Creation time:		Fri, 18 Jul 2014 20:51:24 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		61702
	Content-Type:		image/png
	Hash (crc32c):		f4470729
	Hash (md5):		7073fbb0cd41a2dd6afe0090164791c5
	ETag:			7073fbb0cd41a2dd6afe0090164791c5
	Generation:		1405716684660000
	Metageneration:		2
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>, <<GroupByDomain: google.com>: u'READ'>>

gs://chromium-skia-gm/rendered-skps/desk_baidu_skp/:
gs://chromium-skia-gm/rendered-skps/desk_baidu_skp/bitmap-64bitMD5_9150387651040338742.png:
	Creation time:		Fri, 18 Jul 2014 20:51:24 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		36300
	Content-Type:		image/png
	Hash (crc32c):		4d309e40
	Hash (md5):		ab815d3d31a14a3152dd49b4d7a2d30e
	ETag:			ab815d3d31a14a3152dd49b4d7a2d30e
	Generation:		1405716684995000
	Metageneration:		2
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>, <<GroupByDomain: google.com>: u'READ'>>
gs://chromium-skia-gm/rendered-skps/desk_baidu_skp/bitmap-64bitMD5_9723462985729020720.png:
	Creation time:		Fri, 18 Jul 2014 20:51:25 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		28450
	Content-Type:		image/png
	Hash (crc32c):		95502d84
	Hash (md5):		a48480a8667c7bc9060a3a767c31a750
	ETag:			a48480a8667c7bc9060a3a767c31a750
	Generation:		1405716685298000
	Metageneration:		2
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>, <<GroupByDomain: google.com>: u'READ'>>
gs://chromium-skia-gm/rendered-skps/desk_baidu_skp/bitmap-64bitMD5_987771683121993764.png:
	Creation time:		Fri, 18 Jul 2014 20:51:25 GMT
	Cache-Control:		private, max-age=0
	Content-Encoding:	identity
	Content-Length:		4080
	Content-Type:		image/png
	Hash (crc32c):		4cdfb5d2
	Hash (md5):		27bb9bfc0715813b1a4eb4dd03de778d
	ETag:			27bb9bfc0715813b1a4eb4dd03de778d
	Generation:		1405716685585000
	Metageneration:		2
	ACL:		<Owner:00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd,
<<UserById: 00b4903a97149f98c03d9e192e5baa7ac7cdac7c396df4e4648822c1c13b5bcd>:
u'FULL_CONTROL'>, <<GroupByDomain: google.com>: u'READ'>>
TOTAL: 5 objects, 146722 bytes (143.28 KB)

[borenet, 2014-07-18 22:11:12]

Looks mostly good, but I'd like to avoid piling more straw onto build_step.py's
fragile back...

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/build_step.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:60: ]
I would strongly prefer that these go into gs_utils instead of build_step.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:35: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
On 2014/07/18 21:10:25, epoger wrote:
> Actually, I guess now (before we start uploading these rendered SKP images) is
a
> good time to ask: Should we create a new bucket specifically for them, rather
> than uploading them into gs://chromium-skia-gm/rendered-skps ?
> 
> I think a separate bucket is better.  (It allows us to set bucket
> permissions/configs that are appropriate for each use.)  What do you think?
> 
> Shall I ask to have a new "chromium-skia-skp-images" bucket created for this
> purpose?  (Consistent with the "'chromium-skia-skp-summaries" bucket we had
> created for the summary files.)

Sounds good to me, although I don't know why we need the chromium prefix.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:37: gs_bucket = gs_bucket[5:]
GS_PREFIX = 'gs://'
if gs_bucket.startswith(GS_PREFIX):
  gs_bucket = gs_bucket[len(GS_PREFIX):]

[epoger, 2014-07-21 13:42:51]

Thanks, Eric... (and Ravi, PTAL)

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/build_step.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:60: ]
On 2014/07/18 22:11:12, borenet wrote:
> I would strongly prefer that these go into gs_utils instead of build_step.

Given that the buildbots write SKP files into Google Storage, but individual
developers (i.e. users of the Skia repo) never do, it seems like these
configurations should live within the buildbot repo, not common.

So I can think of 3 options.  I will happily do any of them; you tell me which
one you want:
1. Move these constants into gs_utils.py in the common repo.
2. Define them within upload_rendered_skps.py, and any other build steps that
need them import them from there.
3. Define them within a new shared module in the buildbot repo
("skp_playback.py"?)
4. Something else you come up with

Also, would you like me to leave BOTO_CREDENTIALS_FILE defined here or move it
elsewhere?  (Again, I think it's buildbot-specific, not appropriate for the
common repo)

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:35: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
On 2014/07/18 22:11:12, borenet wrote:
> On 2014/07/18 21:10:25, epoger wrote:
> > Shall I ask to have a new "chromium-skia-skp-images" bucket created for this
> > purpose?  (Consistent with the "'chromium-skia-skp-summaries" bucket we had
> > created for the summary files.)
> 
> Sounds good to me, although I don't know why we need the chromium prefix.

I don't know either, but hinoka@ asked us to in http://crbug.com/372905 ('please
create 2 new Google Storage buckets for Skia team (or can I just do it
myself?)').

Filed http://crbug.com/395615 ('please create 2 new Google Storage buckets for
Skia team') to get this new bucket created.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:37: gs_bucket = gs_bucket[5:]
On 2014/07/18 22:11:12, borenet wrote:
> GS_PREFIX = 'gs://'
> if gs_bucket.startswith(GS_PREFIX):
>   gs_bucket = gs_bucket[len(GS_PREFIX):]

Done.

[rmistry, 2014-07-21 13:56:53]

LGTM

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:35: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
On 2014/07/21 13:42:51, epoger wrote:
> On 2014/07/18 22:11:12, borenet wrote:
> > On 2014/07/18 21:10:25, epoger wrote:
> > > Shall I ask to have a new "chromium-skia-skp-images" bucket created for
this
> > > purpose?  (Consistent with the "'chromium-skia-skp-summaries" bucket we
had
> > > created for the summary files.)
> > 
> > Sounds good to me, although I don't know why we need the chromium prefix.
> 
> I don't know either, but hinoka@ asked us to in http://crbug.com/372905
('please
> create 2 new Google Storage buckets for Skia team (or can I just do it
> myself?)').
> 
> Filed http://crbug.com/395615 ('please create 2 new Google Storage buckets for
> Skia team') to get this new bucket created.

Since these buckets are created under the c-i-t umbrella and likely billed
through them, it makes sense that they have the chromium prefix.

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:36: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
In global_variables, gm_summaries_bucket is "chromium-skia-gm-summaries" and
googlestorage_bucket is "gs://chromium-skia-gm", to me it makes sense to have
the values have only the names of the bucket and the prefix should not have to
be specified. This will simplify callers who will assume that the bucket names
will not contain prefixes.

If you do change that then you will have to update all references that call
googlestorage_bucket and this may be be out of the scope of this CL, leaving the
decision up to you.

[borenet, 2014-07-21 14:07:47]

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/build_step.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:60: ]
On 2014/07/21 13:42:51, epoger wrote:
> On 2014/07/18 22:11:12, borenet wrote:
> > I would strongly prefer that these go into gs_utils instead of build_step.
> 
> Given that the buildbots write SKP files into Google Storage, but individual
> developers (i.e. users of the Skia repo) never do, it seems like these
> configurations should live within the buildbot repo, not common.
> 
> So I can think of 3 options.  I will happily do any of them; you tell me which
> one you want:
> 1. Move these constants into gs_utils.py in the common repo.
> 2. Define them within upload_rendered_skps.py, and any other build steps that
> need them import them from there.
> 3. Define them within a new shared module in the buildbot repo
> ("skp_playback.py"?)
> 4. Something else you come up with
> 
> Also, would you like me to leave BOTO_CREDENTIALS_FILE defined here or move it
> elsewhere?  (Again, I think it's buildbot-specific, not appropriate for the
> common repo)

I like #1 and #3 (though I really don't like the "playback" term; it confuses me
for some reason), and possibly another option would be to create a new
gs_utils.py in skia-buildbot which just imports * from gs_utils in common repo
and adds whatever buildbot-specific stuff we want.

And really, it's not a crime to have variables shared by multiple build steps in
this file.  I just get nervous every time this file gets touched because of the
potential for disaster.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:62: BUILDBOT_PATH, 'third_party',
'chromium_buildbot', 'site_config', '.boto')
On 2014/07/18 21:10:24, epoger wrote:
> This is where we already put the .boto file on the bots... we can change this
> path if we want, once old_gs_utils.py is gone.  (Unless we need the
> chromium_buildbot code to use these same credentials???)

If it's okay with you, let's leave it as-is, since it'll need to be there
eventually when we're in sync with upstream code.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:35: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
On 2014/07/21 13:42:51, epoger wrote:
> On 2014/07/18 22:11:12, borenet wrote:
> > On 2014/07/18 21:10:25, epoger wrote:
> > > Shall I ask to have a new "chromium-skia-skp-images" bucket created for
this
> > > purpose?  (Consistent with the "'chromium-skia-skp-summaries" bucket we
had
> > > created for the summary files.)
> > 
> > Sounds good to me, although I don't know why we need the chromium prefix.
> 
> I don't know either, but hinoka@ asked us to in http://crbug.com/372905
('please
> create 2 new Google Storage buckets for Skia team (or can I just do it
> myself?)').
> 
> Filed http://crbug.com/395615 ('please create 2 new Google Storage buckets for
> Skia team') to get this new bucket created.

Rules is rules I guess.

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:18: GS_PREFIX = 'gs://'
This could go into gs_utils as it may be useful elsewhere.

[epoger, 2014-07-21 20:01:32]

Thanks, guys!  I think it's cleaner now... please see as of patchsets 4+5.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/build_step.py (right):

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:60: ]
On 2014/07/21 14:07:46, borenet wrote:
> On 2014/07/21 13:42:51, epoger wrote:
> > On 2014/07/18 22:11:12, borenet wrote:
> > > I would strongly prefer that these go into gs_utils instead of build_step.
> > 
> > Given that the buildbots write SKP files into Google Storage, but individual
> > developers (i.e. users of the Skia repo) never do, it seems like these
> > configurations should live within the buildbot repo, not common.
> > 
> > So I can think of 3 options.  I will happily do any of them; you tell me
which
> > one you want:
> > 1. Move these constants into gs_utils.py in the common repo.
> > 2. Define them within upload_rendered_skps.py, and any other build steps
that
> > need them import them from there.
> > 3. Define them within a new shared module in the buildbot repo
> > ("skp_playback.py"?)
> > 4. Something else you come up with
> > 
> > Also, would you like me to leave BOTO_CREDENTIALS_FILE defined here or move
it
> > elsewhere?  (Again, I think it's buildbot-specific, not appropriate for the
> > common repo)
> 
> I like #1 and #3 (though I really don't like the "playback" term; it confuses
me
> for some reason), and possibly another option would be to create a new
> gs_utils.py in skia-buildbot which just imports * from gs_utils in common repo
> and adds whatever buildbot-specific stuff we want.

Cool idea.  I went with it... in order to do it without "import * from gs_utils"
(which is considered dangerous) I had to modify the structure of common's
gs_utils.py in https://codereview.chromium.org/405083005/ ('use better mechanism
for enums in gs_utils.py')
> 
> And really, it's not a crime to have variables shared by multiple build steps
in
> this file.  I just get nervous every time this file gets touched because of
the
> potential for disaster.

https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts...
slave/skia_slave_scripts/build_step.py:62: BUILDBOT_PATH, 'third_party',
'chromium_buildbot', 'site_config', '.boto')
On 2014/07/21 14:07:46, borenet wrote:
> On 2014/07/18 21:10:24, epoger wrote:
> > This is where we already put the .boto file on the bots... we can change
this
> > path if we want, once old_gs_utils.py is gone.  (Unless we need the
> > chromium_buildbot code to use these same credentials???)
> 
> If it's okay with you, let's leave it as-is, since it'll need to be there
> eventually when we're in sync with upstream code.

Now, users of gs_utils.py within buildbot automatically get the credentials from
this filepath, unless they ask for something different.

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/upload_rendered_skps.py (right):

https://codereview.chromium.org/405653004/diff/40001/slave/skia_slave_scripts...
slave/skia_slave_scripts/upload_rendered_skps.py:36: gs_bucket =
skia_vars.GetGlobalVariable('googlestorage_bucket')
On 2014/07/21 13:56:52, rmistry wrote:
> In global_variables, gm_summaries_bucket is "chromium-skia-gm-summaries" and
> googlestorage_bucket is "gs://chromium-skia-gm", to me it makes sense to have
> the values have only the names of the bucket and the prefix should not have to
> be specified. This will simplify callers who will assume that the bucket names
> will not contain prefixes.
> 
> If you do change that then you will have to update all references that call
> googlestorage_bucket and this may be be out of the scope of this CL, leaving
the
> decision up to you.

Yes, I agree that it would be better for those bucket names in global_variables
to be consistent.

But I think that change will be a bit tricky to stage (due to version skew
between repos in production), so I'd like to tackle that in a separate CL.

For now, I have created the with_gs_prefix() and without_gs_prefix() methods in
gs_utils.py so that we can safely use these global variables whether they
contain the prefix or not.

[borenet, 2014-07-21 20:22:28]

I like it!  LGTM with question.

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/utils/gs_utils.py (right):

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
slave/skia_slave_scripts/utils/gs_utils.py:18: sys.path.insert(0,
_COMMON_REPO_PATH)
Doesn't fix_pythonpath take care of this?

[epoger, 2014-07-21 20:26:51]

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/utils/gs_utils.py (right):

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
slave/skia_slave_scripts/utils/gs_utils.py:18: sys.path.insert(0,
_COMMON_REPO_PATH)
On 2014/07/21 20:22:28, borenet wrote:
> Doesn't fix_pythonpath take care of this?

What fix_pythonpath?  As far as I know, there's no module or function by that
name within buildbot/slave.

Currently, build_step.py does this itself.  ("Add important directories to the
PYTHONPATH")

[borenet, 2014-07-21 20:31:31]

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
File slave/skia_slave_scripts/utils/gs_utils.py (right):

https://codereview.chromium.org/405653004/diff/80001/slave/skia_slave_scripts...
slave/skia_slave_scripts/utils/gs_utils.py:18: sys.path.insert(0,
_COMMON_REPO_PATH)
On 2014/07/21 20:26:51, epoger wrote:
> On 2014/07/21 20:22:28, borenet wrote:
> > Doesn't fix_pythonpath take care of this?
> 
> What fix_pythonpath?  As far as I know, there's no module or function by that
> name within buildbot/slave.
> 
> Currently, build_step.py does this itself.  ("Add important directories to the
> PYTHONPATH")

Yep, I see that now.  I added one to skia/tools, but it's not really needed in
buildbot/slave because build_step.py can take care of it.  Carry on!

[epoger, 2014-07-21 20:33:57]

The CQ bit was checked by epoger@google.com

[commit-bot: I haz the power, 2014-07-21 20:35:09]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/epoger@google.com/405653004/80001

[commit-bot: I haz the power, 2014-07-21 20:35:18]

Change committed as 68c4f171aa73f1164ed88ea204b23e1f1a3e2e94