Summary:
We'll be adding the new periodic file updates task to run in parallel. This patch
moves the existing one to make it clear it's running on buildbot, so we don't get confused
later on.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1436369
Differential Revision: https://phabricator.services.mozilla.com/D681
***
Bug 1436369 Add taskcluster periodic file updates r=callek
Reviewers: Callek
Reviewed By: Callek
Differential Revision: https://phabricator.services.mozilla.com/D683
***
Bug 1436469 Fix task definition r=callek
***
Bug 1436469 Move periodic-file updates docker image r=callek
Summary:
We'll be adding the new periodic file updates task to run in parallel. This patch
moves the existing one to make it clear it's running on buildbot, so we don't get confused
later on.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1436369
Differential Revision: https://phabricator.services.mozilla.com/D681
***
Bug 1436369 Add taskcluster periodic file updates r=callek
Reviewers: Callek
Reviewed By: Callek
Differential Revision: https://phabricator.services.mozilla.com/D683
***
Bug 1436469 Fix task definition r=callek
***
Bug 1436469 Move periodic-file updates docker image r=callek
Summary:
We'll be adding the new periodic file updates task to run in parallel. This patch
moves the existing one to make it clear it's running on buildbot, so we don't get confused
later on.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1436369
Differential Revision: https://phabricator.services.mozilla.com/D681
***
Bug 1436369 Add taskcluster periodic file updates r=callek
Reviewers: Callek
Reviewed By: Callek
Differential Revision: https://phabricator.services.mozilla.com/D683
***
Bug 1436469 Fix task definition r=callek
***
Bug 1436469 Move periodic-file updates docker image r=callek
Summary:
We'll be adding the new periodic file updates task to run in parallel. This patch
moves the existing one to make it clear it's running on buildbot, so we don't get confused
later on.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1436369
Differential Revision: https://phabricator.services.mozilla.com/D681
- add balrog submit-toplevel - this replaces the final portion of the updates builder.
- rename balrog transform to balrog_submit, because it's for balrog locale submission
- make this default to the 'promote' phase. balrog and beetmover currently take the current
phase, which isn't always the wanted behavior.
- rename balrog publish to balrog schedule
- add balrog secondary push and secondary scheduling, for RCs
- remove the release_updates transforms
- make the task.py balrog transforms smarter
- get rid of the release_balrog_publishing transforms; ad a generic worker_type transform
- add BALROG_ACTIONS to scriptworker.py
- add get_balrog_action_scope()
- remove the unused balrog channel scopes
MozReview-Commit-ID: 369ACiOAd5F
Also add rc-{google-play-track,rollout-percentage} for RC pushapk.
One nice side effect of using the same push-apk kind: we don't re-run push-apk during the ship_fennec relpro flavor if we've run the ship_fennec_rc flavor with the same build. (Google Play would reject the same buildid.)
This is really for bug 1433536, but MozReview is forcing me to include this patch with the others for reasons.
MozReview-Commit-ID: 69ymqVLv9E2
This used to only be relevant to Devedition and Firefox releases.
In bug 1433536 we're going to add RC Fennec releases. Let's rename
the parameter now, for less parameters churn.
MozReview-Commit-ID: 28e1Y5FG4On
When we branched to beta, the MinGW build started failing with a strange error
like "could not find the robustcheckout Mercurial extension". We disabled it
for a while, but now we're re-enabling it (and fixing the problem.)
The root culprit of this was that we were using the incorrect mozconfig. MinGW
does all sorts of stuff in the mozconfig, but the beta branch overrides the
mozconfig using platform_overrides in
testing/mozharness/configs/builds/branch_specifics.py
We avoid this override by changing the MinGW platform so it doesn't match
and the mozconfig doesn't get overridden.
MozReview-Commit-ID: JkETWCRHacO
Here we're adding/updating support for the promote/push/ship phases
for fennec, devedition, and firefox. These are now keyed off of the new
shipping_phase and shipping_product attributes as much as possible.
MozReview-Commit-ID: Fkg8jTPeZHZ
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
This patch adds the `release_deps` transform, which adds every
kind-dependency task that has the same product as a task dependency
(with some exceptions).
This patch made it clear that we need a standard way of defining
product.
MozReview-Commit-ID: 4xOJRQSCTgF
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
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
We were building some Android nightly platforms on push, because we
didn't add them explicitly to the remove list.
I think longer term, we'll want to have `product` and
`release_promotion_action` attributes set in a standard manner, that we
can use to filter these things more intelligently.
MozReview-Commit-ID: KNZ7vxc3gRo
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
This patch adds the initial `release-uptake-monitoring` kind, and adds
it to the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: 3RDMNGrbBwD
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
This patch adds the initial `release-mark-as-shipped` kind, and adds it to
the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: F8AYscJQWlh
This hooks up the `target_tasks_method`s and the
`release_promotion_flavor`s for these four release promotion flavors.
We also add some maple support and add `version_display.txt` to the
decision task sparse checkout so we can read the version number during
decision/action task time.
MozReview-Commit-ID: CdxUUXZtXO0
This patch creates a new `filter_beta_release_tasks` function. By
pulling this logic out of `mozilla_beta_tasks`, we can reuse it in the
release promotion `target_tasks_method`s.
MozReview-Commit-ID: Kwk3jgtooCS
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
for: Run buildbot's periodic_file_update job scheduled via taskcluster.
I messed up thinking this was filter-out not filter in the target task method.
I'm also renaming the target_task method in order to avoid these decision jobs
from needing to contact balrog for partial data (because it had 'nightly' in the
target task name.
MozReview-Commit-ID: 3uetnWG4vnW
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
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
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
