Armen Zambrano's battlefield: December 2011

Thursday, December 22, 2011

talos.zip, talos.json and you

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:

Download talos_from_source_code.py
Which downloads http://hg.mozilla.org/mozilla-central/raw-file/default/testing/talos/talos.json
Which contains where to download the talos.zip from (http://build.mozilla.org/talos/zips/talos.zip - accessible to build machines)

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