Commits that get re-pushed to try don't show up in the treeherder UI
Categories
(Tree Management :: Treeherder: Frontend, defect)
Tracking
(Not tracked)
People
(Reporter: bgrins, Unassigned)
Details
STR:
- Make a commit on m-c
./mach try -b o -p linux64 -u none./mach try -b o -p linux64 -u none(again)
Expected: On the second push I see my commit in the treeherder UI.
Actual: On the second push I only see the temporary commit made for try and not my actual commit.
Example first push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a742a4746d109b401c7a71b7444818bbd1198ec:
5a742a4746d1BG try: -b o -p linux64 -u none --artifact
bde20db467a1BG Commit 1
Example second push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e6eef2df893577c6dc1e076823bcba961e7b67ee:
e6eef2df8935BG try: -b o -p linux64 -u none --artifact
|
Reporter | |
Comment 1•6 years ago
|
||
When this happens I can work around it by digging up through parents of the temporary try commit on the hg server (for example https://hg.mozilla.org/try/rev/e6eef2df893577c6dc1e076823bcba961e7b67ee, who's parent is Commit 1: https://hg.mozilla.org/try/rev/bde20db467a1740ded50c7a2fe8abcfa8d1aa717).
But it makes it a lot harder to scan if I have a bunch of treeherder tabs opened, or if I'm linking back from a perfherder page to try and figure out what the 'new' revision is.
|
||
Comment 2•6 years ago
|
||
Bug 1626685 is the right place to do this: Treeherder says that was the only commit in your push because pushlog told it that was the only commit, and pushlog is the tool that Mozilla invented to pretend that hg commits happened at a different time than when they really did happen, so it's the one that should pretend the push included things that were already pushed.
|
||
Comment 3•6 years ago
|
||
Note if treeherder used json-automationrelevance most cases like this would be caught (e.g. https://hg.mozilla.org/try/json-automationrelevance/e6eef2df893577c6dc1e076823bcba961e7b67ee).
Description
•