Only generate zips for Chrome extension samples whose contents have changed.

Only generate zips for Chrome extension samples whose contents have changed.

  * Implement a _parse_source_data method to parse sample sources more efficiently.
  * Generate a hash of all source code for each sample.
  * Add hash to zip files in a file named VERSION.
  * Do not write zip files for samples where the hash has not changed.
  * Print modified zips in the 'Following files have changed' warning.
  * Sort keys in samples.json alphabetically when writing that file.

BUG=61024
TEST=See bug

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=65591

[kurrik.chromium, 2010-10-28 21:47:13]

This should fix the zips issue, although it's hard to test until the modified
zips themselves are in source control :(

Haven't tested on windows, would you be able to help me with that?

Thanks,
~Arne

[asargent_no_longer_on_chrome, 2010-10-28 23:06:40]

lgtm. I'll give it a try on windows too.

http://codereview.chromium.org/4106007/diff/1/3
File chrome/common/extensions/docs/build/directory.py (right):

http://codereview.chromium.org/4106007/diff/1/3#newcode630
chrome/common/extensions/docs/build/directory.py:630: sample_hashpath =
os.path.join(sample_dirname, 'VERSION')
Is 'VERSION' some magic zipfile property key or something, or does this mean
each zip file will contain a file named VERSION with the hash string in it? If
the latter, maybe it should be called SIGNATURE or HASH or CHECKSUM?

Also, I noticed in the python zipinfo docs something called the 'extra' property
with a format defined by pkzip. It might be complicated to use, but if you're
feeling ambitious it would be cool the see if you could stuff the hash in there
instead of in a user-visible file.

[kurrik.chromium, 2010-10-29 00:19:43]

http://codereview.chromium.org/4106007/diff/1/3
File chrome/common/extensions/docs/build/directory.py (right):

http://codereview.chromium.org/4106007/diff/1/3#newcode630
chrome/common/extensions/docs/build/directory.py:630: sample_hashpath =
os.path.join(sample_dirname, 'VERSION')
It was an additional file - I think I was looking for the name CHECKSUM (HASH
seemed confusing for anyone curious about it) but I think this was an ugly
approach.

I had looked at using ZipFile.comment (.extra had a lot of baggage to use
correctly - search for "extra field: (Variable)" in
http://www.pkware.com/documents/casestudies/APPNOTE.TXT if you want to see) but
the zipfile package didn't seem to be writing that value correctly as a
file-level attribute.

On a hunch, I tried setting the comment property on the ZipInfo structure for
manifest.json and it seemed to persist in the file.  I've changed the code to
use that instead, which should keep the hash hidden.  The zipfile implementation
on Windows might be implemented differently here, so I'd appreciate it if you
could try out this code to see if it looks like it's working properly.

On 2010/10/28 23:06:40, Antony Sargent wrote:
> Is 'VERSION' some magic zipfile property key or something, or does this mean
> each zip file will contain a file named VERSION with the hash string in it? If
> the latter, maybe it should be called SIGNATURE or HASH or CHECKSUM?
> 
> Also, I noticed in the python zipinfo docs something called the 'extra'
property
> with a format defined by pkzip. It might be complicated to use, but if you're
> feeling ambitious it would be cool the see if you could stuff the hash in
there
> instead of in a user-visible file.