This is due to the nature of the mozharness setup where once a change is landed all jobs start running the same code and it does not matter on which branch that job is running.
I have recently landed some code that is now active on Ash (and soon on Try) that will read a manifest file that points your jobs to the right mozharness repository and revision. We call this process to "pin mozhaness". In other words, what we do is to fix an external factor to our job execution.
This will allow you to point your Try pushes to your own mozharness repository.
In order to pin your jobs to a repository/revision of mozharness you have to change a file called mozharness.json which indicates the following two values:
- "repo": "https://hg.mozilla.org/build/mozharness",
This is a similar concept as talos.json introduced which locks every job to a specific revision of talos. The original version of it landed in 2011.
Even though we have a similar concept since 2011, that doesn't mean that it was as easy to make it happen for mozharness. Let me explain a bit why:
- For talos, mozharness has been checking out the right revision of talos.
- In the case of mozharness, we can't make mozharness check itself out.
- Well, we could but it would be a bigger mess
- Instead we have made buildbot ScriptFactory be a bit more flexible
- Enable on Try
- Free up Ash and Cypress
- They have been used to test custom mozharness patches and the default branch of Mozharness (pre-production)
- Enable the feature on all remaining Gecko trees
- We would like to see this run at scale for a bit before rolling it out
- This will allow mozharness changes to ride the trains
Thanks for Rail for all his patch reviews and Jordan for sparking me to tackle it.
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.