Thursday, December 22, 2011, talos.json and you

I have deployed today a small change that modifies how we deploy 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 we place under build.m.o will require a commit on the tree
  • Only when the change lands on the repo that will be used
  • A newer will only be used from that changeset onwards
  • Any regressions caused by the new 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 through the try server and use compare-talos
  • We don't need a downtime anymore to land a
  • The new cannot affect any other branches
  • We can run an old changeset with the 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"

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,


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


  1. this is amazing. A big step forward for making talos changes and getting them deployed.

    Well done!

  2. Awesome! Thanks Armen!

  3. Thank you guys! I'm glad it helps.