Closed Bug 1154796 Opened 6 years ago Closed 6 years ago

make a copy of mozharness and put it in gecko tree


(Release Engineering :: Applications: MozharnessCore, defect)

Not set


(firefox40 fixed, firefox41 fixed, firefox42 fixed, firefox-esr38 fixed)

Tracking Status
firefox40 --- fixed
firefox41 --- fixed
firefox42 --- fixed
firefox-esr38 --- fixed


(Reporter: jlund, Assigned: jlund)




(4 files, 1 obsolete file)

this will initially be for internal testing (so it does not have to be mirrored)

this ticket tracks:

part 1 - putting a copy of mozharness on ash project repo

part 2 - putting a copy of mozharness on trunk (m-c) related repos

part 3 - putting a copy of mozharness across all stabilizing/release repos
as discussed over irc yesterday. This is a straight up copy of hg.m.o/build/mozharness with two differences:

1) there is no
2) I modified the existing README.txt to point out that this is a copy and based off of:

I left mozharness.json in there for now so that as we transition, I don't break existing jobs that are still using the pin.

this patch will be a no-op until we turn it on everywhere.
Attachment #8629158 - Flags: review?(mshal)
Comment on attachment 8629158 [details] [diff] [review]

Looks good! Sorry for already bitrotting you in bug 1179382 - feel free to bring in the recent production branch and carry r+ forward.
Attachment #8629158 - Flags: review?(mshal) → review+
Assignee: nobody → jlund
Closed: 6 years ago
Resolution: --- → FIXED
this is asking for two things:

for a review of an update to the in-tree copy of mozharness to sync with latest prod mh repo rev: 43f7600b8c80

and to be able to uplift this across all the branches with r=mshal, a=testing

again, it will be a no-op until I land:
Attachment #8630741 - Flags: review?(mshal)
Comment on attachment 8630741 [details] [diff] [review]

It looks like a few files were removed in the latest production rev of mozharness, but are still in-tree with this patch:

Only in ./configs: update_tests
Only in ./configs/vcs_sync:
Only in ./configs/vcs_sync:
Attachment #8630741 - Flags: review?(mshal) → feedback+
thanks for the catch. verified this time by diffing deleted files.
Attachment #8630741 - Attachment is obsolete: true
Attachment #8631113 - Flags: review?(mshal)
Comment on attachment 8631113 [details] [diff] [review]

Looks good!
Attachment #8631113 - Flags: review?(mshal) → review+
Keywords: leave-open
Resolution: FIXED → ---
Depends on: 1181713
Depends on: 1181724
Depends on: 1181793
verified locally with (only dotfiles differ):

> diff -r . $DOWNLOADS/mozharness-4a31e6739409 > /tmp/diff
Attachment #8631685 - Flags: review?(mshal)
Attachment #8631685 - Flags: review?(mshal) → review+
Comment on attachment 8631685 [details] [diff] [review]

Attachment #8631685 - Flags: checked-in+
Attachment #8634813 - Flags: review?(ryanvm)
Attachment #8634813 - Flags: review?(ryanvm) → review+
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
On second thought, we decided on IRC to go with mozharness rev cd537fcb6ff0 as the final base rev for the release branches.
Jordan, what is the canonical location of mozharness development at the moment? Is it still or

I ask now because I got the information that I should land all my patches to mozilla-central and not in the other repository given that it is not used anymore. But yesterday I have seen that several test harnesses report a script_revlink of mozharness to Treeherder which still points to /build/mozharness. Als checking this repository I see active development! I'm kinda confused now about where to land changes.
Flags: needinfo?(jlund)
That script_revlink should be dropped.

The Firefox OS team was landing there since they had not yet moved to the in-tree mozharness.
We should make the original place read/only.
(In reply to Henrik Skupin (:whimboo) from comment #21)
> Jordan, what is the canonical location of mozharness development at the
> moment? Is it still or

there is still a small tail of things that need cleaning up: and I just dep'd a small bug specifically to remove script_revlink: bug 1208117

all mh automation scripts bar some releng services (b2g_bumper, vcs_sync) should be using the gecko-tree based mh. please land there. we can't make the original read/only as b2g_bumper/vcs_sync still need to push there. It is forked. We could rename the build/mozharness to clear up confusion.
Flags: needinfo?(jlund)
Thanks Jordan. Good to know that all of our code landed correctly then.
You need to log in before you can comment on or make changes to this bug.