mozharness: config
Oct. 11th, 2011 05:05 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
escapewindowMozharness is a configuration-driven script harness
How is configuration specified in Mozharness?
- A script can define an optional initial config, as a dictionary or a config file.
-
Next, if we specify
--config-file FILEon the command line, that file's contents will be added toself.config. -
Finally, command line options are added to
self.config.
If the same config key is specified in multiple locations, the command line takes precedence over the config file, which takes precedence over the initial config [file].
(command line options > config file > initial config > initial config file)
How does a script add command line options?
The command line options are all optparse-based.
Since there's a global list of command line arguments for all mozharness scripts, I'm currently passing in an additional list from scripts to add to that global list.
What does a config file look like?
Here's a json config file, and a WIP python config file.
We can currently specify anything here. I have a config file well-formedness checker, but I'd love to test for misspellings or missing/extraneous config options as well.
How do we set the config to read-only?
This is handled by locking the ReadOnlyDict.
I cover why here.
What is the volatile config?
After locking the read-only config, mozharness dumps a copy of the running config in a file called localconfig.json, which can be reused or inspected later.
If you specify set of actions to run, that information will currently be saved with the rest of your config. The next time someone runs the script with that config file, that set of non-default actions might be unexpected and undesirable.
Previously, I discarded action config before dumping that file. In the talosrunner branch, I'm now moving action-specific config to self.config['volatile_config']; we'll have the choice whether to re-use that or ignore it in future runs.
If I ever fully support --dry-run / --noop, that will likely be another candidate for a volatile config option.
