If a change is committed while we're regenerating stale files, we should just bail and let the next job handle the refresh.
PiperOrigin-RevId: 510453613
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
These files get automatically updated as post-submit actions, and there's no reason to ever used the checked in versions. Daily run staleness test verify that those don't go out of date.
PiperOrigin-RevId: 496800868
I went ahead and deleted the update_file_list.sh script, because (a)
there was no good reason for it to be in a separate script and (b) we
now need to handle the well-known types in addition to file_lists.cmake.
With this change, we just invoke the staleness tests from the main
script to update everything.
While I was at it I made a couple small fixes:
- Don't skip the update step just because the previous commit was by
"Protobuf Team Bot". Copybara commits use this name and we still want
to do the auto-update step after them.
- Include the CL number in the description if the previous commit came
from a CL.
PiperOrigin-RevId: 487231324
Mike Kruskal
deannagarcia
Adam Cozzette