872007 - Need to handle branch specific mozharness configs

Status: RESOLVED INVALID

(Release Engineering :: General, defect)

Description

[Andrew Halberstadt [:ahal]]

In bug 855893 we decided to move away from the puppetagain mozbase packages on m-c/inbound, but keep using them on b2g18 (to avoid uplifting tons of mozbase fixes). This means mozharness needs to have some special config that is only set when running against the b2g18 branch. This is something that afaik we haven't had to do yet.

I think the only way to do this currently is to call the mozharness script with a special value from the buildbot-configs when running b2g18. I'm just not sure if this is a precedent I should be setting, or if there is a better way of solving the problem.

Aki, is there some way you would prefer to tackle this? Or is the above pretty much the best way to go?

Comment 1

[Aki Sasaki (not active)]

I think our options are either a) putting some config in-tree, having the script read that, and behave accordingly (we could also make a default behavior if the in-tree config doesn't exist), or b) command-line driven behavior per comment 0.

I'm open to either.  (b) will be reconfig-driven.  If we were going to live with this for a long time, I would lean towards (a), but aiui we can make the new behavior default and just override on the b2g18* branches, which will go away at some point.  So in this case I don't have a strong opinion.

Comment 2

[Andrew Halberstadt [:ahal]]

(In reply to Aki Sasaki [:aki] from comment #1)
> I think our options are either a) putting some config in-tree, having the
> script read that, and behave accordingly (we could also make a default
> behavior if the in-tree config doesn't exist), or b) command-line driven
> behavior per comment 0.
> 
> I'm open to either.  (b) will be reconfig-driven.  If we were going to live
> with this for a long time, I would lean towards (a), but aiui we can make
> the new behavior default and just override on the b2g18* branches, which
> will go away at some point.  So in this case I don't have a strong opinion.

I agree that a) seems like a better long term solution. But I'm not sure that this is something that we will need to do much, so I'm leaning towards the simpler solution for now. I guess if it turns out that this is a common need we can always revisit. The fact that this 'hack' will die when b2g18 does is another reason I'm leaning towards b).

Comment 3

[Andrew Halberstadt [:ahal]]

Sounds like we are in agreement. In the case of b) I guess there isn't really anything to do for this bug..