My args.gn file, if it matters:

  is_debug = false
  dcheck_always_on = true
  use_goma = true
  goma_dir = "/work/goma"
  target_os = "chromeos"

.gclient file:

  solutions = [
    {
      "managed": False,
      "name": "src",
      "url": "https://chromium.googlesource.com/chromium/src.git",
      "custom_deps": {},
      "deps_file": ".DEPS.git",
      "safesync_url": "",
    },
    {
      "managed": True,
      "name": "src-internal",
      "url": "https://chrome-internal.googlesource.com/chrome/src-internal.git",
      "deps_file": ".DEPS.git"
    },
  ]
  target_os = ['chromeos']

Per dpranke@, a temporary work-around is to delete build/util/LASTCHANGE and rerun gclient runhooks, which will cause LASTCHANGE.committime to be regenerated.

I *think* this'll only happen if you

1) have a branch with local commits
2) fetch origin containing thakis's change
3) rebase your branch on top of that before running gclient runhooks
4) then run gclient runhooks

At that point, lastchange.py will think that LASTCHANGE didn't change, and won't write the .committime file, but then the build will expect it to exist, and break.

so, I don't think the bots will hit this (which is why they didn't all immediately break) and most devs may not, either.

Downgrading to P1 accordingly, but I'm posting a fix for it now.

I wrote a long comment along the lines of "not sure how this can possibly happen", but I lost it when colliding with Dirk's comment. Sounds like he's working on a fix (thanks!), so giving to him.

Given that this should only happen in corner cases (which branch are you on? What did you run before building? Any merge stuff?), there's an easy workaround, and it will go away over time, the default priority is probably fine.

Actually, in the case I outlined in #c5, I don't think the problem would've occurred, because rebasing should've changed the hash. You would have to do something where you picked up the new lastchange.py but the hash didn't change, and I don't know how you'd do that under normal circumstances.

Regardless, I think my proposed fix is a conservative but correct thing that should handle whatever the weird case was.

jdufault, did you maybe not `gclient runhooks` after rebasing?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea3f82d03831c13bd1bc7277334fd313af7f86b3

commit ea3f82d03831c13bd1bc7277334fd313af7f86b3
Author: Dirk Pranke <dpranke@chromium.org>
Date: Thu Aug 16 22:17:50 2018

Always write //build/util/LASTCHANGE.committime.

When we added LASTCHANGE.committime in r583420, we missed a
case where we might not write it in the hook, and in that
situation the build would fail due to the file being missing.

TBR=thakis@chromium.org
BUG= 875039 

Change-Id: I5c596f55fe90bc5f5175c74ba27e218f108f843b
Reviewed-on: https://chromium-review.googlesource.com/1178892
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583852}
[modify] https://crrev.com/ea3f82d03831c13bd1bc7277334fd313af7f86b3/build/util/lastchange.py

Here are repro instructions:

$ git checkout 4c984bc7664755d701c75b49b795678e164551e3^
Previous HEAD position was 4c984bc76647 Make BUILD_DATE based off the last commit time instead of the current time.
HEAD is now at e0903d18987a Convert PepperTCPSocketMessageFilter to use the mojo host resolver.
$ rm build/util/LASTCHANGE build/util/LASTCHANGE.committime
$ gclient runhooks
Running hooks: 100% (75/75), done.
$ ls build/util/
branding.gni     java_action.py*   LASTCHANGE.dummy  lastchange.pyc       version.gni  webkit_version.h.in
BUILD.gn         LASTCHANGE        lastchange.gni    lib/                 version.py*
java_action.gni  LASTCHANGE.blink  lastchange.py*    process_version.gni  version.pyc
$ git checkout 4c984bc7664755d701c75b49b795678e164551e3
Previous HEAD position was e0903d18987a Convert PepperTCPSocketMessageFilter to use the mojo host resolver.
HEAD is now at 4c984bc76647 Make BUILD_DATE based off the last commit time instead of the current time.
$ gclient runhooks
Running hooks: 100% (75/75), done.
$ ls build/util/
branding.gni     java_action.py*   LASTCHANGE.dummy  lastchange.pyc       version.gni  webkit_version.h.in
BUILD.gn         LASTCHANGE        lastchange.gni    lib/                 version.py*
java_action.gni  LASTCHANGE.blink  lastchange.py*    process_version.gni  version.pyc

Those instructions as given don't repro for me. Further discussion w/ jdufault led us to discover that he had a //build/.git directory somehow, and it looks like lastchange.py had a bug where it'd look at the hash for that repo, not //.git. That would cause the problem he was seeing.

Marking this as fixed, since the patch I landed would "fix" the problem with .committime not existing. One could argue that we could WontFix this and revert the change instead, and I don't have strong leanings one way or another, though I prefer my patch :).