Need to handle branch specific mozharness configs

RESOLVED INVALID

Status

Release Engineering
General
RESOLVED INVALID
5 years ago
2 months ago

People

(Reporter: ahal, Assigned: ahal)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mozharness])

(Assignee)

Description

5 years ago
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?
(Assignee)

Updated

5 years ago
Flags: needinfo?(aki)

Comment 1

5 years ago
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.
Flags: needinfo?(aki)
(Assignee)

Comment 2

5 years ago
(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).
(Assignee)

Comment 3

5 years ago
Sounds like we are in agreement. In the case of b) I guess there isn't really anything to do for this bug..
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Assignee)

Updated

5 years ago
No longer blocks: 855893
Product: mozilla.org → Release Engineering
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.