1432817 - [in-tree relpro] Delete push-apk-breakpoint task

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect)

Description

[Johan Lorenzo [:jlorenzo]]

We introduced this task in bug 1317783. It used to serve like a "human decision task" when some part of release-promotion weren't in-tree. Now, pushapks safeguarded by action tasks. This makes breakpoints obsolete. Aki wanted to retire this task there, but I don't think the bug has been filed.

On central (bug 1351664), it was planned to serve as a safeguard, in case nightlies are known to be broken (hence we don't want them shipped. However, it's currently a dummy task that automatically resolves.

Then, let's just get rid of this task on every branch.

Comment 1

[Johan Lorenzo [:jlorenzo]]

Was originally filed as https://trello.com/c/VWt0GaoV/118-fennec-get-rid-of-push-apk-breakpoint

Comment 2

[Aki Sasaki (not active)]

If we get rid of this task on Fx59 (currently on beta), we need to uplift bug 1430834 as well. If we let this ride the trains, we're good on Fx60.

Comment 3

[Mihai Tabara [:mtabara]⌚️GMT]

I'd be in favor of letting this ride the trains. We're almost half the cycle.

Comment 4

[Johan Lorenzo [:jlorenzo]]

Attachment: Bug 1432817 - [in-tree relpro] Delete push-apk-breakpoint task

Review commit: https://reviewboard.mozilla.org/r/222420/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/222420/

Comment 5

[Aki Sasaki (not active)]

Comment on attachment 8953154 [details]
Bug 1432817 - [in-tree relpro] Delete push-apk-breakpoint task

https://reviewboard.mozilla.org/r/222420/#review228572

Comment 6

[Mozilla Autoland]

We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg rebase -s def2338a16eddf0cdd3c7845e7d682db7e66f578 -d f6264884db15: rebasing 449415:def2338a16ed "Bug 1432817 - [in-tree relpro] Delete push-apk-breakpoint task r=aki" (tip)
merging taskcluster/docs/kinds.rst
merging taskcluster/taskgraph/target_tasks.py
merging taskcluster/taskgraph/transforms/task.py
merging taskcluster/taskgraph/util/workertypes.py
warning: conflicts while merging taskcluster/taskgraph/target_tasks.py! (edit, then use 'hg resolve --mark')
warning: conflicts while merging taskcluster/taskgraph/util/workertypes.py! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)

Comment 7

[Johan Lorenzo [:jlorenzo]]

Comment on attachment 8953154 [details]
Bug 1432817 - [in-tree relpro] Delete push-apk-breakpoint task

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/222420/diff/1-2/

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/43ceb3930a6f
[in-tree relpro] Delete push-apk-breakpoint task r=aki

Comment 9

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/43ceb3930a6f

Comment 10

[Ionuț Goldan [:igoldan]]

It seems like this bug reduced the build times on Beta. It canceled a strange regression which appeared somewhere around March 1st.

== Change summary for alert #12258 (as of Mon, 12 Mar 2018 13:27:46 GMT) ==

Improvements:

  5%  build times windows2012-32-add-on-devel opt taskcluster-c4.4xlarge     2,689.98 -> 2,567.35

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=12258

Comment 11

[Johan Lorenzo [:jlorenzo]]

Thank you for the praise, but I don't think this patch is related to the perf improvement: it didn't change anything related to Windows. Are you sure it's not something related to the machine configuration, Ionuț?

Comment 12

[Ionuț Goldan [:igoldan]]

(In reply to Johan Lorenzo [:jlorenzo] from comment #11)
> Thank you for the praise, but I don't think this patch is related to the
> perf improvement: it didn't change anything related to Windows. Are you sure
> it's not something related to the machine configuration, Ionuț?

Hmm... Now that you mention that, your question is resonable.
Ted, do you know about some infra changes which influenced these perf improvements?

Comment 13

[(not currently active) Ted Mielczarek]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #12)
> Hmm... Now that you mention that, your question is resonable.
> Ted, do you know about some infra changes which influenced these perf
> improvements?

I do not, sorry. Maybe gps would have a better idea?

Comment 14

[Ionuț Goldan [:igoldan]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #13)
> (In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment
> #12)
> > Hmm... Now that you mention that, your question is resonable.
> > Ted, do you know about some infra changes which influenced these perf
> > improvements?
> 
> I do not, sorry. Maybe gps would have a better idea?

:gps Do you have some clues for this?

Comment 15

[Gregory Szorc [:gps]]

I got nothing. Sometimes the build perf data can be wonky.

Comment 16

[Ionuț Goldan [:igoldan]]

(In reply to Gregory Szorc [:gps] from comment #15)
> I got nothing. Sometimes the build perf data can be wonky.

Then :jlorenzo was right. The perf improvement from comment 10 isn't real.
Sorry for the invalid notification.