Re-adding tools@
On 5/22/14 3:51 PM, Aki Sasaki wrote:
> On 5/22/14 1:04 PM, Armen Zambrano G. wrote:
>>>> For every mozharness config that is used on production let's try to
>>>> create a developer version of it.
> I've long wanted to have a second (or third, even) set of configs that
> would work appropriately for standalone users / developers. These take
> extra effort to write and maintain, however, so they haven't existed up
> to this point. Now it seems like we have passed that point where the
> need for development configs is high enough that they're worth investing in.
>
> There are several approaches we can take; some of these can be used in
> combination.
>
> 1. As you proposed, have separate dev and releng config files. The dev
> config files will often be a subset of the releng config file, but will
> sometimes contain some dev-oriented config that doesn't exist in the
> releng config. There will be a lot of duplication here, but the benefit
> is we will be explicit about it.
>
> 2. Create production and staging config files for releng, and pass
> multiple config files to the script. When we pass the config files via
> command line, the order matters. Bhearsum wrote these for balrog:
>
http://hg.mozilla.org/build/mozharness/file/85bc563cec00/configs/balrog/production.py
>
http://hg.mozilla.org/build/mozharness/file/85bc563cec00/configs/balrog/staging.py
>
> 3. Allow "sourcing" other config files from a config file. They're
> python; they can import other python. We already do this in in-tree
> mozconfig land. The benefit here is we can reduce duplication by having
> a common sourced config, and add/override key/value pairs to each child
> config file. We've intentionally avoided doing this for a very long
> time, since we can introduce enough complexity to make it very difficult
> to determine what you're affecting with a change, but it's powerful.
>
> We're getting to very complex configuration requirements here. I'm
> hoping that having a 2-phase mozharness (aka splitting mozharness, aka
> the mozharness wrapper) will help us reduce individual config file
> complexity.
http://escapewindow.dreamwidth.org/245082.html
>
> On 5/22/14 1:13 PM, Armen Zambrano G. wrote:
>> In the production configs we have hardcoded paths to things like:
>> /tools/buildbot/bin/python
>> which is releng specific.
> Correct. This would either live in the releng- or the
> releng-production-, releng-staging- configs.
>
>> We have created dev specific configs before. I'm just trying to make it
>> easier to spot them and to identify to what production equivalent script
>> they're related to.
>>
>> e.g. desktop_test_config.py VS desktop_automation_config_dev.py
> I think that works. We can also put them in separate directories, or
> prepend dev_. I think we can play with different naming schemes; we
> don't have consistent naming across the prod config files yet.
>
>> On a separate note, do we have a way to access tooltool runtime binaries
>> by providing LDAP credentials?
> I think you have to be in the build network.
>
>> On 14-05-22 04:07 PM, Justin Wood wrote:
>>> why not a global option --developer instead?
> Jordan went down this route with his Firefox desktop build configs, but
> I'm not sure if munging your config files to s,\.py,_dev.py,g if
> self.config.get("developer") will be intuitive or confusing. I'd lean
> towards the latter.
>
>>> That way any script can be used this way?
> I think any script can be used with a different config file specified on
> the command line already.
>
> aki
>
>>> as in, what specifically are you trying to solve this way?
>>>
>>> ~Justin Wood (Callek)