I have deployed today a small change that modifies how we deploy talos.zip to the performance/talos jobs.
In short what the change does is this:
That's it. Nothing else. Nothing more.
How does this help?
- Every new talos.zip we place under build.m.o will require a commit on the tree
- Only when the change lands on the repo that talos.zip will be used
- A newer talos.zip will only be used from that changeset onwards
- Any regressions caused by the new talos.zip will be blamed to a changeset on the tree
- Such changeset can be backed out by anyone without the need of releng
What are other side-effects?
- We can run a talos.zip through the try server and use compare-talos
- We don't need a downtime anymore to land a talos.zip
- The new talos.zip cannot affect any other branches
- We can run an old changeset with the talos.zip that was used for it
- We can extend the talos.json file to control other moving parts like plugins
If we could summarize it in one sentence it would be:
"
One changeset, one talos.zip"
This different model is not new as Jetpack already had it (
jetpack-location.txt).
This model locks every changeset on a tree to a specific state of an external force.
In other words, we can configure parameters from inside tree.
Best regards,
Armen
[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=673131

This work by
Zambrano Gasparnian, Armen is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.