fennec: add source tarball task

NEW
Assigned to

Status

Release Engineering
Release Automation
P1
normal
10 months ago
10 months ago

People

(Reporter: kmoir, Assigned: kmoir)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Assignee)

Description

10 months ago
for release promotion with taskcluster
(Assignee)

Updated

10 months ago
Assignee: nobody → kmoir
(Assignee)

Comment 1

10 months ago
Created attachment 8835137 [details] [diff] [review]
wip patch

not sure if the beetmover bits should be tied in at this point too
(Assignee)

Comment 2

10 months ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=128504fef9cc2b39d921e134fa0a8cf29bf93f82&selectedJob=75659316 

https://public-artifacts.taskcluster.net/QqaXKwjTQRyX-rQjtb5QEw/0/public/full-task-graph.json
(Assignee)

Comment 3

10 months ago
Created attachment 8835511 [details] [diff] [review]
wip patch

https://public-artifacts.taskcluster.net/Mb6D-h2aSUKpn5ds7vTkSw/0/public/full-task-graph.json

Not sure if this is the right approach, if this job should be under android builds or included in another kind
Attachment #8835137 - Attachment is obsolete: true
(Assignee)

Comment 4

10 months ago
Created attachment 8835547 [details] [diff] [review]
wip patch

no sure if this is on the right track or if the source tarball should be included in another kind
Attachment #8835511 - Attachment is obsolete: true
Attachment #8835547 - Flags: feedback?(rail)
Comment on attachment 8835547 [details] [diff] [review]
wip patch

Review of attachment 8835547 [details] [diff] [review]:
-----------------------------------------------------------------

Oooooh! This looks much fancier that https://github.com/mozilla/releasetasks/blob/master/releasetasks/templates/firefox/source.yml.tmpl!

Initially I thought about implementing this task the same way as Firefox (in releasetasks). But this looks much cleaner...

On the other hand generating source tarballs for every CI build is a bit a waste of time and space. If we can limit these only to nightly style graphs, that would be great!
Attachment #8835547 - Flags: feedback?(rail) → feedback+
(Assignee)

Comment 6

10 months ago
Created attachment 8835683 [details] [review]
pull request
Attachment #8835547 - Attachment is obsolete: true
(Assignee)

Comment 7

10 months ago
Created attachment 8837750 [details] [review]
PR
Attachment #8835683 - Attachment is obsolete: true
Priority: -- → P1
(Assignee)

Comment 8

10 months ago
Rail could you look at my PR and provide feedback?
Flags: needinfo?(rail)
Comment on attachment 8837750 [details] [review]
PR

I commented in the PR
Flags: needinfo?(rail)
(Assignee)

Comment 10

10 months ago
Rail, I committed some more changes to the PR, ran the tests locally and they all passed

https://github.com/mozilla/releasetasks/pull/213
(Assignee)

Comment 11

10 months ago
rail let me know if I'm missing anything in the updated pr
Flags: needinfo?(rail)
(Assignee)

Comment 12

10 months ago
Created attachment 8840622 [details] [review]
includes work for bug 1338161
Attachment #8837750 - Attachment is obsolete: true
The PR looks good to me. Thanks!
Flags: needinfo?(rail)
(Assignee)

Comment 14

10 months ago
So looking at the tasks associated with the candidates_fennec hook that aki added last night, I don't see the source tarball task. 

https://bugzilla.mozilla.org/show_bug.cgi?id=1338161#c2

https://tools.taskcluster.net/task-group-inspector/#/QQjEh3q1TOu2liv57iHawg?_k=xa1zb8

Is this expected or should it be included when we run releasetasks but not against the graph on jamun?
Flags: needinfo?(aki)

Comment 15

10 months ago
IIRC, what we discussed in Toronto was:

1) we trigger releasetasks.  this can do things like tagging (skip?) and source tarball
2) releasetasks triggers a candidates_fennec type graph for fennec.  this is essentially like the hook, except it populates things like build_number automatically

so the graph i triggered was (2), though manually triggered instead of through releasetasks.  Aiui, bug 1338161 was about adding a decision task to releaserunner that would trigger (2), so triggering releaserunner would trigger both the source tarball and the build.  The way things stand currently , releaserunner will trigger the source tarball, and releaseduty will then have to trigger the candidates_fennec manually after manually updating the build_number etc.
Flags: needinfo?(aki)
(Assignee)

Comment 16

10 months ago
Okay, thanks aki, that clarifies it.
You need to log in before you can comment on or make changes to this bug.