currently this tasks dont exists, but it is on the todo list. tcmigration is for fennec stuff into tree is a nice opportunity to add it.

this is not finnal patch but i need help with: 1) how do I include this publish into publish action (and promote into promote action)? 2) what should be kind dependencies? 3) what should be the email subject/body? since now we will have 2 emails...

(In reply to Rok Garbas [:garbas] from comment #1) > Created attachment 8921473 [details] [diff] [review] > fennec-email-release-drivers.patch > > this is not finnal patch but i need help with: > > 1) how do I include this publish into publish action (and promote into > promote action)? The promote action's kinds are defined here: https://hg.mozilla.org/projects/maple/file/tip/taskcluster/taskgraph/target_tasks.py#l376 The publish action's kinds are defined here: https://hg.mozilla.org/projects/maple/file/tip/taskcluster/taskgraph/target_tasks.py#l395 > 2) what should be kind dependencies? We can start with push-apk for fennec publish, and beetmover-checksums for fennec promote. > 3) what should be the email subject/body? since now we will have 2 emails... https://github.com/mozilla-releng/releasetasks/blob/master/releasetasks/templates/notification/email_release_drivers_task.yml.tmpl#L14 has an example. For publish, maybe "{} {} build{} has been published to Google Play".format(product, version, build_number) For promote, maybe "{} {} build{} is in the candidates directory" We can adjust those in the future as wanted; those subjects will probably work for now.

Comment on attachment 8921473 [details] [diff] [review] fennec-email-release-drivers.patch I think this looks good. I haven't tried using the patch; how does it look? I think it would be good to make the `release-drivers` email list configurable. We don't want to spam release-drivers for our staging runs, for example; we may also push the graph to try as well. Maybe we can specify this by-project: ? On `release` branches we can use release-drivers. On `maple` we can use release+tcstaging@m.c or something. If you can figure out how to make it default to the email of the person who pushed the change, that would be awesome for try; otherwise I'm fine with a default of no email. >+@transforms.add >+def task_name_from_label(config, tasks): >+ for task in tasks: >+ if 'label' not in task: >+ if 'name' not in task: >+ raise Exception("task has neither a name nor a label") Are you seeing tasks with no label or name, or just checking?

:aki I generized the notifications and implemented them in task tranform. also all 3 questions I had I added/fixed in this patch.

Comment on attachment 8922514 [details] [diff] [review] fennec-email-release-drivers.patch Thanks! I'd be fine with followup fixes for the below, but we can fix them before landing too: >diff --git a/taskcluster/ci/release-notify-promote/kind.yml b/taskcluster/ci/release-notify-promote/kind.yml >new file mode 100644 >--- /dev/null >+++ b/taskcluster/ci/release-notify-promote/kind.yml >@@ -0,0 +1,35 @@ >+# This Source Code Form is subject to the terms of the Mozilla Public >+# License, v. 2.0. If a copy of the MPL was not distributed with this >+# file, You can obtain one at http://mozilla.org/MPL/2.0/. >+ >+loader: taskgraph.loader.transform:loader >+ >+transforms: >+ - taskgraph.transforms.task:transforms >+ >+# TODO: >+# kind-dependencies: >+# - release-* >+# maybe more deps (not sure) >+ >+jobs: >+ fennec: >+ label: notify release-drivers about promoting a release a) I think we want labels to not have whitespace. b) we may want this task to notify someone other than release-drivers c) the label will need to be unique, even when we add a firefox release-notify-promote. Maybe fennec-notify-promote or something? >+ notifications: >+ completed: >+ subject: "{config[params][project]} {release_config[version]} build{release_config[build_number]} is in the candidates directory" >+ message: "{config[params][project]} {release_config[version]} build{release_config[build_number]} is in the candidates directory" >+ ids: >+ - release-drivers It looks like the ids can be by-project. We don't have to add that this time around. >diff --git a/taskcluster/ci/release-notify-publish/kind.yml b/taskcluster/ci/release-notify-publish/kind.yml >new file mode 100644 >--- /dev/null >+++ b/taskcluster/ci/release-notify-publish/kind.yml >@@ -0,0 +1,35 @@ >+# This Source Code Form is subject to the terms of the Mozilla Public >+# License, v. 2.0. If a copy of the MPL was not distributed with this >+# file, You can obtain one at http://mozilla.org/MPL/2.0/. >+ >+loader: taskgraph.loader.transform:loader >+ >+transforms: >+ - taskgraph.transforms.task:transforms >+ >+# TODO: >+# kind-dependencies: >+# - release-* >+# maybe more deps (not sure) >+ >+jobs: >+ fennec: >+ label: notify release-drivers about publishing a release Same here, maybe fennec-notify-publish >diff --git a/taskcluster/docs/kinds.rst b/taskcluster/docs/kinds.rst >--- a/taskcluster/docs/kinds.rst >+++ b/taskcluster/docs/kinds.rst >@@ -214,16 +214,24 @@ kind depend on all the signed multi-loca > in order to make the decision. > > push-apk > -------- > PushApk publishes Android packages onto Google Play Store. Jobs of this kind take > all the signed multi-locales (aka "multi") APKs for a given release and upload them > all at once. They also depend on the breakpoint. > >+release-notify-publish >+---------------------- >+Email release-drivers when publishing a release. >+ >+release-notify-promote >+---------------------- >+Email release-drivers when promoting a release. If we allow for other email lists, we could just s,release-drivers ,, >diff --git a/taskcluster/taskgraph/target_tasks.py b/taskcluster/taskgraph/target_tasks.py >--- a/taskcluster/taskgraph/target_tasks.py >+++ b/taskcluster/taskgraph/target_tasks.py >@@ -380,33 +380,41 @@ def target_tasks_candidates_fennec(full_ > and, eventually, uploading the tasks to balrog.""" > filtered_for_project = target_tasks_nightly_fennec(full_task_graph, parameters) > > def filter(task): > if task.label in filtered_for_project: > if task.kind not in ('balrog', 'push-apk', 'push-apk-breakpoint'): > if task.attributes.get('nightly'): > return True >+ if task.kind in ('release-notify-promote', >+ ): >+ return True We're likely going to have devedition, fennec, and firefox notify tasks in the release-notify-promote kind. We should probably filter by product, like we do on the below line. That probably means we need to add product somewhere in the task payload, or filter by task.label.startswith("fennec") or ...? > @_target_task('publish_fennec') > def target_tasks_publish_fennec(full_task_graph, parameters): > """Select the set of tasks required to publish a candidates build of fennec. > Previous build deps will be optimized out via action task.""" > filtered_for_candidates = target_tasks_candidates_fennec(full_task_graph, parameters) > > def filter(task): > # Include candidates build tasks; these will be optimized out > if task.label in filtered_for_candidates: > return True >+ if task.kind in ('release-notify-publish', >+ ): Here too.

> >+@transforms.add > >+def task_name_from_label(config, tasks): > >+ for task in tasks: > >+ if 'label' not in task: > >+ if 'name' not in task: > >+ raise Exception("task has neither a name nor a label") > > Are you seeing tasks with no label or name, or just checking? I think this is a bug in task transform. there is an assertion check somewhere in task transform which checks that name schema field is not present. this snippet of code is taken from job transform, but using job transform is an overkill in this situation. For such simple tasks as notifying release drivers, it should be possible to only use task transform, without any special custom transform. A quick look at the kinds and transforms tells me that there is almost 1:1 ratio. For each kind, we can find a custom transform. I think this defeats the purpose of using yml since the majority of the logic is kept in python and not declaratively stated in yml files. This is, of course, the problem of task transform not being generic enough. Or maybe we should use python instead of those yml files, so we don't have to invent yet another language in yml :)

This addresses all issues you mentioned so far. Shortly I will also create a `release-drivers-staging` id on pulse-notify and maybe we should wait until that gets deployed before we merge this. The only thing I couldn't implement is sending to emails when on try. If this is something we want to do maybe it makes sense to implement it in pulse-notify. Or maybe we just wait until we move away from pulse-notify all together and notify via taskcluster. Should we create a trello card for this and squeeze it in tcmigration work? ofcourse marked with low prio.

:jlorenzo Could you deploy new version of pulse-notify with `release-drivers-staging` group?

:aki i fixed few typos in new patch.

Comment on attachment 8922849 [details] [diff] [review] adding release-drivers-staging notifications id Review of attachment 8922849 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. Deployed in production: * https://github.com/mozilla-releng/pulse-notify/commit/8dcb88545fbe372f4062932073b080ab836763aa * https://dashboard.heroku.com/apps/release-notifications/activity/builds/11be0408-7b36-45b3-b119-06eb0e519667

Comment on attachment 8922861 [details] [diff] [review] fennec-email-release-drivers.patch I think we shouldn't remove the 'fennec' from the version bump task. I can add those back in before landing on maple.

:aki the "-fennec" will be appended later on.