"Actual commit differs from requested commit" error

[Ms2ger]

See http://build.servo.org/builders/mac-dev-unit/builds/4846 for example

[Ms2ger]

The git step also says

fatal: Unable to create '/Users/servo/buildbot/slave/mac-rel-css/build/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

[aneeshusa]

This is a new step I added as a safeguard because Buildbot frankly sucks at git fetch, and often silently continues with the wrong commit.

Looking at the build logs for failed builds linked above (e.g. http://build.servo.org/builders/mac-dev-unit/builds/4849/steps/git/logs/stdio), it seems all of these are failing on our Mac builders, specifically due to another git process running in the same directory? It seems likely to me that a git process crashed at some point and didn't clean up after itself, meaning further git invocations don't go through. (This occurs because Buildbot doesn't just rm -rf the whole directory, but uses git clean -f -f -d -x, which I believe keeps the .git directory.)

I'll take a look on the builders; I'm open to suggestions on the error message to make it more useful.

[KiChjang]

Could it also be a force retry that broke stuff? (e.g. servo/servo#14632)

[aneeshusa]

I doubt a force retry is to blame.

I've cleaned up all the errant index.lock files I could find (after checking no builds were being on each builder):

• arm32 on servo-linux-cross1
• mac-rel-css, mac-rel-wpt1 on servo-mac2
• mac-rel-css on servo-mac4
• mac-dev-unit on servo-macpro1

I confirmed there's none left via

root@servo-master1$ salt '*' cmd.run 'ls -a ~buildbot/slave/*/build/.git/index.lock'

All builders reported no index.lock files

It's possible this is affecting Windows builder(s), I didn't look at/touch those.

[aneeshusa]

Linked PRs are merged now, so looks like this is fixed (at least for now). Closing, re-open if it happens again.