This allows firefox and thunderbird builds to avoid using each others bits.
MozReview-Commit-ID: KYQYDd2tkGj
--HG--
extra : rebase_source : 42f1d13ec609f066cb3bd3050ed894296b72d982
These two new attributes will help us determine which tasks belong in which release promotion graphs. In the future, we'll specify these for all shippable builds as well, and we can reduce the usage of the `product` keys. However, sometimes we need `product` to differ from `shipping-product` (e.g., `mobile` vs `fennec`; in this case we mean `stage_product` vs `shipping_product`), so I haven't yet touched those key/value pairs.
MozReview-Commit-ID: LEuf4CS277Q
--HG--
extra : rebase_source : 4971883500658ace209bec97a639a54c94292b50
Instead of relying on environment variables, pass these in as parameters.
MozReview-Commit-ID: An58Bu2kd1g
--HG--
extra : rebase_source : 9c7b6beb13b676a3376a897f2c8143cc042b8276
This template takes a single integer as input, and sets the 'task_duplicates'
attribute on any tasks that were explicitly specified by try_task_config.json.
This means dependent tasks or 'always_target' tasks will not be rebuilt.
To support this template, the apply_jsone_templates morph now requires the
entire try_task_config object instead of just the templates.
MozReview-Commit-ID: DwxUtlC5VD5
--HG--
extra : rebase_source : c57a80ada2fc4591a5ce4c94965b8c9f02bb53b1
The motivation for this change is to create a 'rebuild' template that sets
'attributes.task_duplicates'. A nice side effect is that if any of 'task'
or 'attributes' aren't explicitly set, we can ignore the result which means
we don't need to have a whole bunch of 'else' clauses in the templates.
MozReview-Commit-ID: DX3UyFGb4ff
--HG--
extra : rebase_source : b768cb9f9df3cb22827209519f1cd2a4944af74f
Tasks that have the 'always_target' attribute set will be always be included
in the target_task_graph, regardless of target task filtering.
Furthermore, if they were only added because of this attribute (i.e, the
filters would have excluded the task), then the task will be a candidate for
optimization even if the 'optimize_target_tasks' parameter is False.
MozReview-Commit-ID: 9eoVJ5qpAMO
--HG--
extra : rebase_source : 9635002720d088ca9870649f3143d6293c666610
This patch adds the `release-notify-promote` and `release-notify-publish` kinds. It also genericizes all the notifications, and updates the kinds that use those notifications.
MozReview-Commit-ID: 9ymXKzthVF4
--HG--
extra : rebase_source : 6d7db48afa14e4124834321784da65e8d1e84c98
This patch adds the beetmover-cdns kind, and adds it to
`publish_fennec`.
This was the first non-buildbot-bridge, non-dummy relpro task, so this
needed a new transform.
This patch also updates the `previous_graph_kinds` and updates the
beetmover scopes in scriptworker.py.
MozReview-Commit-ID: 3rpkjuLjjXz
--HG--
extra : rebase_source : d491f1ce5d10ee8f2602698236106007e203c358
This patch adds the initial `release-version-bump` kind, and adds it to
the `publish_fennec` `target_tasks_method`.
It also adds support for `next_version`.
MozReview-Commit-ID: 9YRswddeuZ3
--HG--
extra : rebase_source : 991cbf89b40c4ef980c42251001e81be5cedaf00
This patch adds the initial `release-uptake-monitoring` kind, and adds
it to the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: 3RDMNGrbBwD
--HG--
extra : rebase_source : f504c8e173337d45bc9f374bd0349c6823b50ffb
This patch adds the initial `release-bouncer-aliases` kind, and adds it
to the `publish_fennec` `target_tasks_method`.
It also adds the ability to specify the `tuxedo_server_url`
`by-project`.
MozReview-Commit-ID: 9I4IaUlbCCD
--HG--
extra : rebase_source : d0ed88a687ef6fb9f97dc67c0f04742bbfeb201d
This patch adds the initial `release-mark-as-shipped` kind, and adds it to
the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: F8AYscJQWlh
--HG--
extra : rebase_source : 9522b95f65b5b373a54bc0fc01a20c72adbee0cb
This patch adds the first releasetask as a new kind. To support this, we
added a new `release-promotion` flag in the buildbot job. If this is
set, we use the new `bb_release_worker` function; otherwise we fall back
to the `bb_ci_worker` function (this is the old behavior, factored out
into a separate function).
We also added `build_number` and `release_promotion` attributes in the
task definition. Finally, `build_number` now defaults to 1, allowing us
to create the task graph locally without forcing us to set
`BUILD_NUMBER` in the environment.
MozReview-Commit-ID: 8vNMHJemqAG
--HG--
extra : rebase_source : c8816d3e7b2f5358ea51ee8d5fb12585e67e9853
Add a release promotion custom action for releng's TC release promotion migration work.
This action generates a graph dependent on previously built tasks. To track these, we add the `do_not_optimize` and `existing_tasks` parameters. The `do_not_optimize` parameter specifies tasks that we want to explicitly exclude from taskgraph optimization. The `existing_tasks` parameter specifies a label-to-taskid map for tasks from previous graphs.
MozReview-Commit-ID: 1vKrNUavM4V
--HG--
extra : rebase_source : b8ba95d270aafe1464c2b3bfc318b9568500a7a1
With this in place, all `-j`obs will not run by default on try. This will omit
such jobs in most try pushes even if files-changed matches. This is
unfortunate, but better than running them unconditionally. Fuzzy selections,
and later `just try it` pushes, are the ultimate solution here.
With this change, a push with no try syntax or try_task_config.json will schedule
no tasks at all.
MozReview-Commit-ID: FGjqlDW1FT6
--HG--
extra : rebase_source : 727ceafb1b6d24f83c0c7382b6a877ecb65863ab
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : 25e9966696d78d899783d9f38533d5ae66f9ccb9
extra : source : b53ff084c2d7968a1d9864d1343f2d9381fb652b
In preparation for much more thorough optimization of task-graphs, this
makes a few changes:
* optimization is split into thre phases, with task removal in one phase
(following dependency links) and task replacement in the next (in the
reverse order).
* optimization uses class instances instead of functions for optimizations;
this allows different functions for different phases, and also leaves open
the possibility of composing optimizations.
* the replacement phase can also support removal; this is when utility tasks
like symbol uploads can be optimized away iff their parent task is
optimized.
MozReview-Commit-ID: C5QznNpwqXn
--HG--
extra : rebase_source : cf1654036041a64398a2cd38e35e8de4f3596ff9
extra : source : c25af2c111a5be4e3381d0b002641691d15fe4e8
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : 03a10610aa3337269fe76a1196bb9b1665e1ab20
extra : source : b53ff084c2d7968a1d9864d1343f2d9381fb652b
In preparation for much more thorough optimization of task-graphs, this
makes a few changes:
* optimization is split into thre phases, with task removal in one phase
(following dependency links) and task replacement in the next (in the
reverse order).
* optimization uses class instances instead of functions for optimizations;
this allows different functions for different phases, and also leaves open
the possibility of composing optimizations.
* the replacement phase can also support removal; this is when utility tasks
like symbol uploads can be optimized away iff their parent task is
optimized.
MozReview-Commit-ID: C5QznNpwqXn
--HG--
extra : rebase_source : c6e2ff90316d43cd93826de5c30a1936f19c01ca
extra : source : c25af2c111a5be4e3381d0b002641691d15fe4e8
Per IRC dicussion, there is no technical or policy restriction on dependencies
within a task kind. Update the documentation to remove the out-of-date mention
of this limitation. In particular, toolchain build tasks tend to depend on
each other.
MozReview-Commit-ID: K6p0mxyjcvY
--HG--
extra : rebase_source : 9439503e8f0a278b1bb41d8a71a2d31d5fc9c0e8
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : bb1d194b49caa4b69ce8faf9f324c80850d15d3f
extra : histedit_source : a933e0a6f8819b8d0e9220ecc10c34d096a0d477
In preparation for much more thorough optimization of task-graphs, this
makes a few changes:
* optimization is split into thre phases, with task removal in one phase
(following dependency links) and task replacement in the next (in the
reverse order).
* optimization uses class instances instead of functions for optimizations;
this allows different functions for different phases, and also leaves open
the possibility of composing optimizations.
* the replacement phase can also support removal; this is when utility tasks
like symbol uploads can be optimized away iff their parent task is
optimized.
MozReview-Commit-ID: C5QznNpwqXn
--HG--
extra : rebase_source : 661c6b7134c03481c3aa7520d892cc3565b04d85
extra : histedit_source : f0d058df0c8fae075c72f57d8b764f485eb4f6ed
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : fdd8c3cfb9abf759a3c43c5713e62e4772c5bd06
In preparation for much more thorough optimization of task-graphs, this
makes a few changes:
* optimization is split into thre phases, with task removal in one phase
(following dependency links) and task replacement in the next (in the
reverse order).
* optimization uses class instances instead of functions for optimizations;
this allows different functions for different phases, and also leaves open
the possibility of composing optimizations.
* the replacement phase can also support removal; this is when utility tasks
like symbol uploads can be optimized away iff their parent task is
optimized.
MozReview-Commit-ID: C5QznNpwqXn
--HG--
extra : rebase_source : f8e65ee3ebb9fb584b00ee0db518b790a9c1b233
Tom Prince
Aki Sasaki
Andrew Halberstadt
Rok Garbas
Rail Aliiev
Mike Hommey
Dustin J. Mitchell
Brian Stack
Justin Wood
Phil Ringnalda
Simon Fraser
Sebastian Hengst
Wes Kocher
Ralph Giles
Nick Fitzgerald
Ryan VanderMeulen