New issue
Advanced search Search tips

Issue 872407 link

Starred by 3 users

Issue metadata

Status: Available
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 913435
issue 913585

Blocking:
issue 869348



Sign in to add a comment

Consider getting rid of all generated commit hashes embedded in the binary (aka get id of lastchange.py)

Project Member Reported by thakis@chromium.org, Aug 8

Issue description

We 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.)
 
We show the revision in chrome://version; I'm expecting we'd keep that around?
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 :-))
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.
Right, having the revision in about:gpu is pretty useful. But maybe you can shift things around as you describe.
I also find having the revision in about:gpu useful.

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.

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".
Blocking: 869348
Cc: thomasanderson@chromium.org
Blockedon: 913435
Blockedon: 913585
Project Member

Comment 12 by bugdroid1@chromium.org, 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

Comment 13 by halcanary@google.com, Today (15 hours ago)

Cc: -halcanary@chromium.org halcanary@google.com

Sign in to add a comment