Consider getting rid of all generated commit hashes embedded in the binary (aka get id of lastchange.py) |
||||||
Issue descriptionWe currently run a bunch of hooks that embed the "current commit hash" of various repos (src, angle, skia, ...) in the binary. That's suboptimal for swarming since it means binary hashes change on every commit, even for commits that shouldn't affect the final binary (comment changes, non-source changes to e.g. docs, test-only changes, etc.). This bug is about trying to stop embedding some or all of these commit hashes. I know of the following: - gen/angle/id/commit.h. Says jmadill: "The main use case for the commit.h hashing is to invalidate ANGLE's shader cache on a binary format change. The shader cache is used in Chrome and other ANGLE customers to increase browser & web page load speed. Any change to ANGLE's binary format makes it incompatible with prior versions." Sounds like the shader cache code could instead use a hash of the binary format source code, or a hash of the binary format serialization .a lib. - src/skia/ext/skia_commit_hash.h. Added in https://chromium.googlesource.com/chromium/src/+/5cacab3ad1c742e08fc26e666171e6b3e4bd99fe ; sounds like it only shows up on chrome://gpu -- could maybe just delete without much ill effects? halcanary? - GPU_LISTS_VERSION . Also only used on chrome://gpu - The actual LASTCHANGE file. Mostly embedded in a bunch of .rc files on Windows; also used as "did the last commit change" input in various places. (I'm not planning to work on this soon; just filing this so I have a list of the things that currently exist.)
,
Aug 8
Maybe? But even if we keep that, that would only affect the chrome binary, and making e.g. angle use something different would make content_shell revision-independent and layout test results more cacheable. (But this is all firmly in handwave territory :-))
,
Aug 8
Right, I'm not objecting to getting rid of as many hashes as we can, just pointing out there's at least one that I probably wouldn't get rid of. Ideally we can make that get embedded as late in the process as possible.
,
Aug 8
Right, having the revision in about:gpu is pretty useful. But maybe you can shift things around as you describe.
,
Aug 9
I also find having the revision in about:gpu useful.
,
Aug 9
I see that I can get the git commit of "Chrome/70.0.3514.0" (for example) by looking at https://chromium.googlesource.com/chromium/src/+/70.0.3514.0 . Maybe that's not so bad.
,
Aug 9
You can also go to https://omahaproxy.appspot.com/, paste in the version in the "Version Information" box in the lower left and click "Lookup".
,
Oct 25
,
Nov 29
,
Dec 10
,
Dec 10
,
Dec 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/acfba20e2719aa962c60332519a2e8080eab4e0b commit acfba20e2719aa962c60332519a2e8080eab4e0b Author: Nico Weber <thakis@chromium.org> Date: Mon Dec 10 22:55:48 2018 Remove LASTCHANGE_STRING from chrome_version.h.in It appears unused. Bug: 872407 Change-Id: I791b0bf5e395a3b20c219160a3356269e84d1a7b Reviewed-on: https://chromium-review.googlesource.com/c/1370488 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#615295} [modify] https://crrev.com/acfba20e2719aa962c60332519a2e8080eab4e0b/chrome/common/BUILD.gn [modify] https://crrev.com/acfba20e2719aa962c60332519a2e8080eab4e0b/chrome/common/chrome_version.h.in
,
Today
(15 hours ago)
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dpranke@chromium.org
, Aug 8