685761 - mozharness release scripts should be able to use buildbot-configs/mozilla/[staging_]release-*.py

Status: RESOLVED FIXED

(Release Engineering :: Applications: MozharnessCore, defect, P5)

Description

[Aki Sasaki (not active)]

Bug 679153 addresses some of the mozharness config override issues, but not all.

It will most likely still be a pain to do a staging release -- either copying and editing the various .json and .py mozharness config files in the official mozharness repo, or creating a user repo.

Mozharness can already grok a .py config file. If we could read and use mozilla/release-fennec-mozilla-beta.py for all of our config needs (or w/e main config file we're using), that would be a win.

A couple things:

* mozharness currently expects a .py config file to give a dict named 'config'; the release config files create a dict named 'releaseConfig'.  We can either search for either/or, or put a |config = releaseConfig.copy()| or the like at the end of each release config file.

* we want to be very clear when naming things in the release config files so it makes sense for both the entire release suite and each individual script.

Comment 1

[Aki Sasaki (not active)]

If the releaseConfig and config dicts look a bit too different, we can also create two dictionaries, e.g.

config['foo'] = releaseConfig['bar']

Comment 2

[Aki Sasaki (not active)]

If/when we do this, we have a bootstrap issue in that mozharness and buildbot-configs are both required to start running the script.

We can do this by cloning both in the factory before launching the script.

Comment 3

[Aki Sasaki (not active)]

Two more things in this brainstorm-in-a-bug:

* We can potentially have a mozharness release config file that parallels each buildbot-configs release config file.

** That means we have to edit 2 different config files per release, but only 2, and any differences between the two would hopefully be less confusing than they would be in a single file.

** As we port factories over to mozharness, we pare down the dependencies on the buildbot-configs release config file to 0.


* We can potentially have a --release-config-file that reads in the release config into self.release_config, and --config-file reads the script-specific config into self.config as usual.

** That would mean we could put any configs-specific-to-this-release in the release config (revision, tag names, version numbers, build numbers, user repo paths, repo_setup flags, etc.) and any generic script configs in the script configs.  Unless the code changes, the script configs should be able to stay static while we update the release config per release.

Comment 4

[Aki Sasaki (not active)]

I already do this quite a bit and can resolve any other outstanding issues as they come up.