I am on archlinux and using git. This issue appeared after running |git mozreview fetch ba5d81c79b957b516221b2a43b50ae764c7be0d5| Log can be found here : https://pastebin.mozilla.org/9029764. Related code seems here : https://dxr.mozilla.org/mozilla-central/rev/b95b1638db48fc3d450b95b98da6bcd2f9326d2f/python/mozbuild/mozbuild/artifacts.py#949-984

Could this be related to bug 1390239 which just got fixed on mozilla-central?

This bug fixes only mercurial and I am a git user so I don't think they are related :/

Unfortunately this looks like an inherent problem with git mozreview and artifact builds. Whenever we try to do an artifact build we attempt to find a changeset locally that's likely to be in an automation push. From hg we use the most recent public changeset, but from git-cinnabar we approximate this with the most recent git revision that has an hg revision known to git-cinnabar. This prevents us from attempting to find local changes in automation, but apparently in the case someone pulls from mozreview we attempt to find the mozreview push head in automation and fail. There is a note on git-cinnabar indicating that it doesn't implement hg phases, so I don't know if there will be a straightforward way to reliably find the last public changeset from git. As a workaround I might recommend applying commits from mozreview manually as patches locally in order to work on top of them.

My rewrite of the artifact searching in bug 1382507 may fix this. But I haven't had time to polish off that series since I was mercilessly torn away from build stuff to get VCS infrastructure upgraded due to the CVE's last week.

CC'ing Mike for further input.

For one, git mozreview fetch could set `cinnabar.data` to `never` (git -c cinnabar.data=never cinnabar fetch ...), which would avoid storing mercurial data for those commits. But more generally, the artifact search code should not stop at the first revision it finds it knows.