Closed Bug 1387135 Opened 7 years ago Closed 7 years ago

Add ability to run artifact builds on try with 'try_task_config.json'

Categories

(Firefox Build System :: Task Configuration, task)

Product:
Firefox Build System
Component:
Task Configuration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla57

People

(Reporter: ahal, Assigned: ahal)

References

Details

Attachments

(4 files)

Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,
59 bytes, text/x-review-board-request
dustin
: review+
Details
Bug 1387135 - Add an 'artifact' try_task_config template to schedule artifact builds,
59 bytes, text/x-review-board-request
dustin
: review+
Details
Bug 1387135 - Add ability to use 'artifact' template to |mach try fuzzy|,
59 bytes, text/x-review-board-request
impossibus
: review+
Details
Bug 1387135 - Tag all tasks with their kind,
59 bytes, text/x-review-board-request
dustin
: review+
Details 
The try_task_config.json mechanism, and a fuzzy try selector that uses it, are both now landed in-tree.

Many moons ago when we first started discussing storing scheduling information in a data structure (as opposed to try syntax), we realized that we would want to be able to not only control *what* jobs run, but also *how* they run.

For that reason, we decided to use a dict with something like:

{
  'my-awesome-task-label': {
     'option1': 'value1',
     'option2': 'value2',
  }
}

I think try syntax's --artifact is a good first candidate to implement as it is really useful and added automatically when an artifact build is detected locally. It is likely going to be the biggest factor that keeps developers from switching away from try syntax.

This bug represents a pretty substantial departure from how target_task methods currently work. So care will need to be taken to get it right. I'm filing this just so it is on the radar and I don't surprise anyone with undesirable changes. I don't plan on working on this just yet.
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

Hey Dustin, I'd like your feedback on this approach before I push much further. I like this because it's very simple from taskcluster's point of view, but it might be too permissive. Here's the patch in action:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=08f07d3383ac56df7076bb42348c85a95c0a89fa

Something I haven't figured out yet, is how will the client (e.g mach try) know which configs to apply to which tasks? Using this artifact example, it would need to know to add this config for 'build' tasks, but not 'test' tasks.

I think we'll need some way of declaring which tasks support what config modifications, maybe using voluptuous schemas? If something along the lines of this patch is ok with you, then this declaration could live client side under /tools/tryselect (where mach try lives) and taskcluster would play dumb and simply update the task config.

Let me know if you have any better ideas!
Attachment #8896102 - Flags: feedback?(dustin)
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review172794

I have a mild aversion to using morphs to semantically change the task-graph -- they're described as syntactic sugar.  We could change that description, of course!

To your questions, a few ideas:

* we're using task tags in action tasks to allow acting on sets of tasks (all mochitests, etc.) - I suspect mach try could do the same.  This would mean the transforms would declare which tasks they can apply to, rather than the reverse.
* rather than merging these snippets with tasks, consider using JSON-e to write task transforms.  This would allow more than just adding object properties and appending to lists. Maybe something like

{
  tasks: {
    "build-linux64/opt": {transforms: ['use-artifact']},
    "build-linux64/debug": {transforms: ['use-artifact']},
  },
  transforms: {
    "use-artifact": { ... json-e here ... }
  }
}

Basically naming transforms per task, and then attaching a library of the transforms referenced.

The json-e expression to merge sub-objects like that gets a little bulky with $merge but we've discussed a $mergeDeep that could be useful.

::: testing/mozharness/scripts/fx_desktop_build.py:128
(Diff revision 1)
>                                             platform_for_log_url,
>                                             write_to_file=True)
>              else:
>                  self.fatal("'stage_platform' not determined and is required in your config")
>  
> -        if self.try_message_has_flag('artifact'):
> +        if self.try_message_has_flag('artifact') or os.environ.get('USE_ARTIFACT'):

I like communicating to jobs with env vars or the like, instead of letting them parse try syntax.  I think my refrigerator has a try-syntax parser in it these days.
Attachment #8896102 - Flags: feedback?(dustin) → feedback+
Assignee: nobody → ahalberstadt
(In reply to Dustin J. Mitchell [:dustin] from comment #4)
> https://github.com/taskcluster/json-e/issues/169

Neat! This is perfect.

(In reply to Dustin J. Mitchell [:dustin] from comment #3)
> Comment on attachment 8896102 [details]
> Bug 1387135 - Add try task config morph
> 
> https://reviewboard.mozilla.org/r/167388/#review172794
> 
> I have a mild aversion to using morphs to semantically change the task-graph
> -- they're described as syntactic sugar.  We could change that description,
> of course!

I originally wrote up a patch that modifies filters (e.g target_task methods) to return { label: task } instead of [label], with the intention of doing the update directly in the target_task method. Then I noticed using a morph was a bit simpler, but I'd be happy to go back to my original plan.

 
> To your questions, a few ideas:
> 
> * we're using task tags in action tasks to allow acting on sets of tasks
> (all mochitests, etc.) - I suspect mach try could do the same.  This would
> mean the transforms would declare which tasks they can apply to, rather than
> the reverse.
> * rather than merging these snippets with tasks, consider using JSON-e to
> write task transforms.  This would allow more than just adding object
> properties and appending to lists. Maybe something like
> 
> {
>   tasks: {
>     "build-linux64/opt": {transforms: ['use-artifact']},
>     "build-linux64/debug": {transforms: ['use-artifact']},
>   },
>   transforms: {
>     "use-artifact": { ... json-e here ... }
>   }
> }
> 
> Basically naming transforms per task, and then attaching a library of the
> transforms referenced.

I think after I posted this (it was late) I came to a similar conclusion. I like this idea.. though can 'transforms' be applied at the target_task stage? Maybe we need to come up with a new terminology here.

So with your proposal, the try_task_config.json might look like:
{
    "tasks": [
        "build-linux64/opt",
        "test-linux64/opt-mochitest-e10s-1"
    ],
    "extra_config": {
        "use-artifact": True,
        "extra-test-harness-args": ["--repeat", 10]
    }
}

This means we wouldn't be able to e.g enable artifact for some builds and disable it for others.. but maybe that's too complicated for a single push and not supporting it is a good thing.
Heh, I think I'm *more* uncomfortable changing tasks in target selection, so .. let's just change the description of morph :)

Hm, I shouldn't have used the word "transform".  This is a JSON-e template which takes a task as input and produces a different task as output.

My example was actually what I was thinking try_task_config.json would look like.  In your suggestion, I don't see what extra_config would mean..
Oh I see. So your example is an improvement on this patch, but it still has this problem:

> Something I haven't figured out yet, is how will the client (e.g mach try) know which configs to apply to which tasks? Using this artifact example, it would need to know to add this config for 'build' tasks, but not 'test' tasks.

I guess I need to look into action tasks + tags for some inspiration.
FTR, I thought you were suggesting that which json-e templates a task can support be baked directly into the task definition. So |mach try| would pass in which templates to apply, and then taskgraph would automatically apply it only to the tasks that have declared they support it.
I've been thinking about this for a bit. Instead of building json-e templates via |mach try|, I think we should just check them into .yml files and have taskgraph load them up and render them with each task json as the context. We can even build which tasks they should apply to directly into the template itself with json-e condition statements. For example:

taskcluster/try_templatest/artifacy.yml
  task:
    $merge:
      - $eval: task
      - $if: task.kind == build
        else: {}
        then:
           # merge in USE_ARTIFACTS=1

The artifact use case is just a boolean switch, but in some cases (like test harness command line flags) we'll want to support strings or even more complicated values. In this case, I think we can pass in additional context from |mach try| and have taskgraph add it to the render context.

This would make the try_task_config.json looks something like this:

{
  "tasks": ["build-linux64/opt", "test-linux64/opt-mochitest-e10s-1"],
  "templates": {
    "artifact": { "use_artifact": true }
  }
}

This would tell taskgraph to apply the "artifact" template (stored somewhere in artifact.yml), with the task json + use_artifact: true as the context. The template would be smart enough to only apply itself to tasks with kind == build.

I'll try to get a proof of concept put up in a bit.
Here's the latest patch in action:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8343632cab895698dfdc65af33d7b2b76ef5c319

I really like this approach. Json-e allows us to keep a lot of the complexity out of taskgraph/tryselect, yet it's also very powerful and flexible. I think we'll be able to build a lot of cool features on top of something like this.
Comment on attachment 8897458 [details]
Bug 1387135 - Add an 'artifact' try_task_config template to schedule artifact builds,

https://reviewboard.mozilla.org/r/168754/#review174128
Attachment #8897458 - Flags: review?(dustin) → review+
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review174112

I like this in principle (and I'm happy you like JSON-e), just some objections to the details..

::: taskcluster/docs/how-tos.rst:314
(Diff revision 3)
> +
> +Modifying Task Behavior on Try
> +``````````````````````````````
> +
> +It's possible to alter the definition of a task with templates. Templates are
> +`JSONe`_ files that live in the `taskgraph module`_. Templates can be specified

"JSON-e"

::: taskcluster/docs/how-tos.rst:330
(Diff revision 3)
> +
> +Each key in the templates object denotes a new template to apply, and the value
> +denotes extra context to use while rendering. When specified, a template will
> +be applied to every task no matter what. If the template should only be applied
> +to certain kinds of tasks, this needs to be specified in the template itself
> +using JSONe `condition statements`_.

A little bit more explicit detail of what the context looks like would be good here - what are the top-level keys, and what do they contain?

::: taskcluster/taskgraph/morph.py:263
(Diff revision 3)
> +
> +    def __call__(self, taskgraph, label_to_taskid):
> +        for task in taskgraph.tasks.itervalues():
> +            for template in self.templates:
> +                context = task.to_json()
> +                context['templates'] = self.templates

itym `context.update(self.templates[template])`?

::: taskcluster/taskgraph/target_tasks.py:67
(Diff revision 3)
>      with open(task_config_file, 'r') as fh:
>          task_config = json.load(fh)
>  
> +    if task_config.get('templates'):
> +        fn = morph.JSONeTemplates(task_config['templates'])
> +        morph.DEFAULT_MORPHS.append(fn)

This is still pretty icky, modifing a constant..

In general, modifying global state as part of task-graph generation is also not great.  What about setting a parameter of some sort instead?

Even that is a little awful since it means changing parameters after the taskgraph generation has started, but in bug 1383880 I'm thinking of doing a pre-taskgraph-generation pass that would determine the kind of try run being done (if any) and set parameters accordingly *before* taskgraph generation starts.  At which point having the list of additional morphs in a parameter would make sense.
Attachment #8896102 - Flags: review?(dustin) → review+
(In reply to Dustin J. Mitchell [:dustin] from comment #6)
> Heh, I think I'm *more* uncomfortable changing tasks in target selection, so
> .. let's just change the description of morph :)

I'm similarly concerned with changing the meaning of `morph` without a suitable way to test morphs and to compare the output of morphs.

Right now the morphs are only exercised when we get to the decision task, and no good way to run them locally. I don't have a great other suggestion here though (I wouldn't want to modify things in the target selection either).
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review174112

> itym `context.update(self.templates[template])`?

It was actually on purpose, but I'd be fine with this change if you prefer. I did it this way because A) might as well put all template context under a new namespace so it's obvious what is coming from the user and what is coming from the task definition, and B) this way a template can see context from other templates being used and try to avoid collisions.

B) is purely hypothetical though, so not a great reason.
(In reply to Justin Wood (:Callek) from comment #19)
> (In reply to Dustin J. Mitchell [:dustin] from comment #6)
> > Heh, I think I'm *more* uncomfortable changing tasks in target selection, so
> > .. let's just change the description of morph :)
> 
> I'm similarly concerned with changing the meaning of `morph` without a
> suitable way to test morphs and to compare the output of morphs.
> 
> Right now the morphs are only exercised when we get to the decision task,
> and no good way to run them locally. I don't have a great other suggestion
> here though (I wouldn't want to modify things in the target selection
> either).

You can run morphs locally with: ./mach taskgraph morphed

Though in order to get this specific morph applied you'd need to create a try_task_config.json file as well as use a parameters.yml file from try.
A few higher-level questions:

Is it worth thinking about implementing these modifications within the task-graph generation itself, using parameters?  So this particular try mode would set some parameters (maybe just parameters['try_knobs'] = try_task_config['knobs']?) and then various bits of taskgraph generation would read from that and set appropriate flags?

And, going the other direction, is it likely that many of these modifications will be paralleled by actions?  For example, a modification to run reftests serially is probably something a dev would also like to do via treeherder in a "Rerun reftests" action with the "serialize tests" checkbox checked.  Is there a way to avoid defining the same thing twice?

And finally, regarding setting up try_task_config.json along with parameters.yml -- why not just load the former and store it as a parameter early in the decision process (while also storing params['try_mode'] = 'try-this')?
One high level idea I just had, why not implement as an optimization. Set the optimization ability on eligible build jobs, and on optimization phase replace the build jobs with AB. that also gives path of least surprise when looking at treeherder incase things pass as artifact build but fail as a normal one. 

Happy to have this implemented however its done.
I think that is what we will eventually do to support automatic artifact builds.  I'm vaguely considering the possibility in bug 1383880, but it's complicated.  I think Andrew is trying to solve the more general question of "how do I affect the content of tasks, instead of just which tasks are run, in a try push".  And optimizations are not a good place to be modifying task contents :)
Comment on attachment 8897459 [details]
Bug 1387135 - Add ability to use 'artifact' template to |mach try fuzzy|,

https://reviewboard.mozilla.org/r/168756/#review174304

cool
Attachment #8897459 - Flags: review?(mjzffr) → review+
(In reply to Justin Wood (:Callek) from comment #23)
> One high level idea I just had, why not implement as an optimization. Set
> the optimization ability on eligible build jobs, and on optimization phase
> replace the build jobs with AB. that also gives path of least surprise when
> looking at treeherder incase things pass as artifact build but fail as a
> normal one. 
> 
> Happy to have this implemented however its done.

Yeah, I should have probably focused on artifact builds in a separate bug, but the hard part here is making this a general purpose thing. Also fwiw, the current |mach try syntax| also automatically schedules artifact builds, and that's without changing the build symbol at all. So imo, this is at least an improvement on the status quo.


(In reply to Dustin J. Mitchell [:dustin] from comment #22)
> A few higher-level questions:
> 
> Is it worth thinking about implementing these modifications within the
> task-graph generation itself, using parameters?  So this particular try mode
> would set some parameters (maybe just parameters['try_knobs'] =
> try_task_config['knobs']?) and then various bits of taskgraph generation
> would read from that and set appropriate flags?

Yeah, I think that would work. So you're suggesting that we get generator.py to read try_task_config.json right at the start and then set both:
parameters['labels'] = try_task_config['tasks']
parameters['templates'] = try_task_config['templates']

I'll code it up so we can see how it looks.


> And, going the other direction, is it likely that many of these
> modifications will be paralleled by actions?  For example, a modification to
> run reftests serially is probably something a dev would also like to do via
> treeherder in a "Rerun reftests" action with the "serialize tests" checkbox
> checked.  Is there a way to avoid defining the same thing twice?

I never thought of that, but yeah I guess you're right. I don't really have the foggiest idea how actions work, but presumably we could also make them apply the same templates that try_task_config uses, right? Seems like it would be the easiest way to prevent duplication.

 
> And finally, regarding setting up try_task_config.json along with
> parameters.yml -- why not just load the former and store it as a parameter
> early in the decision process (while also storing params['try_mode'] =
> 'try-this')?

Bit orthogonal to this bug, but I don't really like 'try_mode' as a formal parameter. I think if try_task_config.json exists, we're doing "try-this" and if it doesn't, we're doing "just-try-it" (conveniently ignoring try syntax for the moment).
(In reply to Andrew Halberstadt [:ahal] from comment #26)
> Yeah, I think that would work. So you're suggesting that we get generator.py
> to read try_task_config.json right at the start and then set both:
> parameters['labels'] = try_task_config['tasks']
> parameters['templates'] = try_task_config['templates']

Yes, although I think those parameter names are too general; it seems like
  parameters['try_task_config'] = try_task_config
would be easiest.

> I never thought of that, but yeah I guess you're right. I don't really have
> the foggiest idea how actions work, but presumably we could also make them
> apply the same templates that try_task_config uses, right? Seems like it
> would be the easiest way to prevent duplication.

I like that. /cc bstack.  One key to making that work would be to align the context provided to try templates with that provided to action templates.  It's defined at https://docs.taskcluster.net/manual/tasks/actions/spec

With that in place, we could define some shared actions by just loading the relevant .yml and sticking it into actions.json.

> Bit orthogonal to this bug, but I don't really like 'try_mode' as a formal
> parameter. I think if try_task_config.json exists, we're doing "try-this"
> and if it doesn't, we're doing "just-try-it" (conveniently ignoring try
> syntax for the moment).

Fair, I'll think about it more in the optimization bug.
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

This needs a re-review.
Attachment #8896102 - Flags: review+ → review?(dustin)
Sorry, I didn't see your comments before pushing this. I think it's probably easiest if you just re-review and add new issues if appropriate.
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review174582

::: taskcluster/docs/how-tos.rst:338
(Diff revision 4)
> +definition (i.e the result of ``task.to_json()``, see the output of ``mach
> +taskgraph full -J`` for examples) plus any extra context passed in from
> +``try_task_config.json`` under the ``templates.<template_name>`` key. For
> +example, with the above ``try_task_config.json`` the artifact context can be
> +accessed with ``templates.artifact.enabled``. See the `existing templates`_ for
> +examples.

I'd like to see this aligned with action tasks.  That would put the existing task definition under `task` in the context.  Thinking a little further, action tasks expect a full task definition from `Queue.task(<taskId>)`, whereas these try templates are going to get a pre-submission task definition that may still contain {relative-datestamp: ..}.  In practice I don't think that will matter.  The other sub-fields of `task.to_json()` (http://gecko.readthedocs.io/en/latest/taskcluster/taskcluster/taskgraph.html#taskgraph-json-format) may be more distraction than utility.

I think the exception to that statement is `kind` -- but again in keeping with action tasks, maybe it makes sense to use the context method of filtering on task tags - https://docs.taskcluster.net/manual/using/actions/spec#action-context

A few other considerations to align the JSON-e context provided to actions and to try templates:

* `taskGroupId` should be null
* `taskId` should be provided (it's `task_id` in `task.to_json()`..)
* what you're calling `templates` should instead be provided under `input`

::: taskcluster/docs/parameters.rst:115
(Diff revision 4)
> +Morphed Set
> +-----------
> +
> +``templates``
> +    List of JSON-e templates to apply to each task. Available templates live in
> +    ``taskcluster/taskgraph/templates``. Enabled on try only.

Is this a list or a dict?

How about naming this `target_task_templates`?

Speaking of which: does order matter?

::: taskcluster/taskgraph/morph.py:264
(Diff revision 4)
> +    def __call__(self, taskgraph, label_to_taskid):
> +        if not self.templates:
> +            return taskgraph, label_to_taskid
> +
> +        for task in taskgraph.tasks.itervalues():
> +            for template in self.templates:

maybe add sorted(..) here just to get a deterministic ordering?

::: taskcluster/taskgraph/parameters.py:42
(Diff revision 4)
>      """An immutable dictionary with nicer KeyError messages on failure"""
>      def check(self):
>          names = set(self)
>          msg = []
>  
> -        missing = PARAMETER_NAMES - names
> +        missing = PARAMETER_NAMES - names - set(['target_task_labels', 'templates'])

let's put this in `TRY_ONLY_PARAMETER_NAMES` or something like that
Attachment #8896102 - Flags: review?(dustin) → review+
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review174582

> I'd like to see this aligned with action tasks.  That would put the existing task definition under `task` in the context.  Thinking a little further, action tasks expect a full task definition from `Queue.task(<taskId>)`, whereas these try templates are going to get a pre-submission task definition that may still contain {relative-datestamp: ..}.  In practice I don't think that will matter.  The other sub-fields of `task.to_json()` (http://gecko.readthedocs.io/en/latest/taskcluster/taskcluster/taskgraph.html#taskgraph-json-format) may be more distraction than utility.
> 
> I think the exception to that statement is `kind` -- but again in keeping with action tasks, maybe it makes sense to use the context method of filtering on task tags - https://docs.taskcluster.net/manual/using/actions/spec#action-context
> 
> A few other considerations to align the JSON-e context provided to actions and to try templates:
> 
> * `taskGroupId` should be null
> * `taskId` should be provided (it's `task_id` in `task.to_json()`..)
> * what you're calling `templates` should instead be provided under `input`

I'm a bit confused on what concretely you want me to do here. Are you saying that the context should look like:

    {
      "task": {
        "payload": { ... },
        "env": { ... },
        ...
      },
      "templates": {
        "artifact": {"enabled": 1},
      },
      "taskGroup": null,
      "taskId": "<task id>"
    }

As you pointed out, the lack of `kind` will break this artifact template as build tasks don't seem to be tagged with anything. Can I leave kind in for the time being? Or should I add a 'build' tag to all build tasks.

> Is this a list or a dict?
> 
> How about naming this `target_task_templates`?
> 
> Speaking of which: does order matter?

Good catch, it's a dict. It doesn't get applied at the target_task stage though, maybe `morph_templates` would be better?

> let's put this in `TRY_ONLY_PARAMETER_NAMES` or something like that

Will do.

Fyi, these do get set by default, so I could remove this change. But it means we'd no longer be able to use an old parameters.yml with `mach taskgraph` or `mach try`. I don't know if that's important or not though.. Maybe it doesn't matter.
(In reply to Andrew Halberstadt [:ahal] from comment #34)
> I'm a bit confused on what concretely you want me to do here. Are you saying
> that the context should look like:

Close.. I'm suggesting:

     {
       "task": {
         "provisionerId": ...,
         "workerType": ...,
         "payload": { "env: ... },
         ...
       },
       "input": {"enabled": 1},
       "taskGroupId": null,
       "taskId": "<task id>"
     }

"input" could also be {"artifacts": {"enabled": 1}} but I have a hard time seeing why one template should have access to values passed to another template.

> As you pointed out, the lack of `kind` will break this artifact template as
> build tasks don't seem to be tagged with anything. Can I leave kind in for
> the time being? Or should I add a 'build' tag to all build tasks.

I think adding the build tag is a good idea.  In fact, tagging every task with its kind isn't a bad idea.

> Good catch, it's a dict. It doesn't get applied at the target_task stage
> though, maybe `morph_templates` would be better?

That works -- then this functionality is a little more general than just modifying try tasks!

> Fyi, these do get set by default, so I could remove this change. But it
> means we'd no longer be able to use an old parameters.yml with `mach
> taskgraph` or `mach try`. I don't know if that's important or not though..
> Maybe it doesn't matter.

Historically we've been pretty strict about parameters.  It caused a little confusion before the default "fetch parameters from the latest push to central" functionality was added, but I think it's a lot better now.
Sorry for the all the rug sweeping. I'm done now.
Blocks: 1391075
Comment on attachment 8896102 [details]
Bug 1387135 - Add ability to apply templates to task definitions via try_task_config.json,

https://reviewboard.mozilla.org/r/167388/#review175052

::: taskcluster/docs/how-tos.rst:290
(Diff revision 7)
> -      "test-windows7-32/opt-reftest-2",
> +        "test-windows7-32/opt-reftest-2",
> -      "test-windows7-32/opt-reftest-3",
> +        "test-windows7-32/opt-reftest-3",
> -      "build-linux64/debug",
> +        "build-linux64/debug",
> -      "source-test-mozlint-eslint"
> +        "source-test-mozlint-eslint"
> -    ]
> +      ]
> +    ]

} :)

::: taskcluster/taskgraph/decision.py:198
(Diff revision 7)
> +    # bother loading them elsewhere
> +    task_config_file = os.path.join(GECKO, 'try_task_config.json')
> +    if project == 'try' and os.path.isfile(task_config_file):
> +        with open(task_config_file, 'r') as fh:
> +            task_config = json.load(fh)
> +        parameters['morph_templates'] = task_config.get('templates')

might want to default this to `{}`?
Comment on attachment 8898000 [details]
Bug 1387135 - Tag all tasks with their kind,

https://reviewboard.mozilla.org/r/169304/#review175058
Attachment #8898000 - Flags: review?(dustin) → review+
Comment on attachment 8897458 [details]
Bug 1387135 - Add an 'artifact' try_task_config template to schedule artifact builds,

https://reviewboard.mozilla.org/r/168754/#review175062
Pushed by ahalberstadt@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a43cb4709418
Add ability to apply templates to task definitions via try_task_config.json, r=dustin
https://hg.mozilla.org/integration/autoland/rev/2fcca8727201
Tag all tasks with their kind, r=dustin
https://hg.mozilla.org/integration/autoland/rev/43d8f62b21c0
Add an 'artifact' try_task_config template to schedule artifact builds, r=dustin
https://hg.mozilla.org/integration/autoland/rev/0c92ba4c6942
Add ability to use 'artifact' template to |mach try fuzzy|, r=maja_zf
Product: TaskCluster → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: