Switching branches in the engine invalidates builds (RBE?)

[gaaclarke]

reproduction steps

git checkout foo
# build your target
git checkout bar
git reset --hard foo
# build your target

observed behavior

The second build started from scratch.

expected behavior

The second build should be the same hash as the last one I built. I would have expected the second build to be a noop.

[matanlurey]

Hmm this is an interesting one.

Can I assume this used to WAI with pre-et workflows?

[gaaclarke]

Pre-et for me was goma. This is possibly an rbe vs goma thing. I wanted to mention it since I saw it on the chance there was something that rang a bell for people familiar with the et codebase.

[matanlurey]

If you try --no-rbe, what happens?

[gaaclarke]

If you try --no-rbe, what happens?

That would take a long time to try =T.

I'm not even sure how one would get this behavior since RBE and et should know nothing about the reset. Maybe the modification time on the files is getting changed when switching branches? So even though I ended up in the same state, the files modification time was updated which triggered them to have to be recompiled.

I think if there is nothing in et that is caching some git internals or file timestamps we can close this. I'm not sure if it will come up a lot, but we can reopen it if we do see it. If it is the timestamp problem, there's nothing we could do to fix it =T

[matanlurey]

I think this is worth re-opening, in the context of improving the engine (even if the fix is not in et).

[matanlurey]

@zanderso Is it worth tracking RBE-specific productivity issues under engine-tool? Is e: rbe a thing?

[zanderso]

There's no e: rbe right now afaik, but we can add one.