Incorrect commit identifier on igalia-jsc32-armv7-ews (https://ews-build.webkit.org/#/workers/81). Earlier this bot was having issues with git (e.g.: https://ews-build.webkit.org/#/builders/38/builds/31141). After the issue was fixed, the commit identifiers incorrectly started from 2@main. e.g.: https://ews-build.webkit.org/#/builders/38/builds/31142, https://ews-build.webkit.org/#/builders/38/builds/31234
This is fallout from https://bugs.webkit.org/show_bug.cgi?id=225616, we have a bad cache. This cache is trivial to clear (it's in .git/identifiers.json), but I don't know how to access this bot. I'll need to explore a bit to understand how we got a bad cache, because that's clearly a bug. But now that we have a bad one, this behavior is not surprising.
(In reply to Jonathan Bedard from comment #1) > This is fallout from https://bugs.webkit.org/show_bug.cgi?id=225616, we have > a bad cache. This cache is trivial to clear (it's in .git/identifiers.json), > but I don't know how to access this bot. Thanks for the tip, I just deleted .git/identifiers.json in igalia-jsc32-armv7-ews-02. > I'll need to explore a bit to understand how we got a bad cache, because > that's clearly a bug. But now that we have a bad one, this behavior is not > surprising. FWIW the issue that Aakash linked to above caused git to exit early for lots of operations, so perhaps this broke some assumption about a git operation that "cannot possibly fail" in the code that manages the identifier cache?
(In reply to Angelos Oikonomopoulos from comment #2) > (In reply to Jonathan Bedard from comment #1) > > This is fallout from https://bugs.webkit.org/show_bug.cgi?id=225616, we have > > a bad cache. This cache is trivial to clear (it's in .git/identifiers.json), > > but I don't know how to access this bot. > > Thanks for the tip, I just deleted .git/identifiers.json in > igalia-jsc32-armv7-ews-02. > > > I'll need to explore a bit to understand how we got a bad cache, because > > that's clearly a bug. But now that we have a bad one, this behavior is not > > surprising. > > FWIW the issue that Aakash linked to above caused git to exit early for lots > of operations, so perhaps this broke some assumption about a git operation > that "cannot possibly fail" in the code that manages the identifier cache? Almost certainly `git log`, I guess I need to start checking exit codes for that process
<rdar://problem/80520002>
Created attachment 433406 [details] Patch
Created attachment 433422 [details] Patch
Comment on attachment 433422 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433422&action=review rs=me > Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py:166 > + return what is the consequence of returning here?
(In reply to Aakash Jain from comment #7) > Comment on attachment 433422 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=433422&action=review > > rs=me > > > Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py:166 > > + return > > what is the consequence of returning here? By returning here, we basically throw out the whole result of `git log`, since we don't cache it until after we finish the commands (because we essentially need to cache it backwards). If we don't have a cache, we compute things the way we did before the cache.
(In reply to Jonathan Bedard from comment #8) > By returning here, we basically throw out the whole result of `git log`, > since we don't cache it until after we finish the commands (because we > essentially need to cache it backwards). If we don't have a cache, we > compute things the way we did before the cache. ok, sounds good.
Created attachment 433452 [details] Patch for landing
Committed r279898 (239648@main): <https://commits.webkit.org/239648@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433452 [details].