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.

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

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.

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

Comment on attachment 8953154 [details] Bug 1432817 - [in-tree relpro] Delete push-apk-breakpoint task https://reviewboard.mozilla.org/r/222420/#review228572

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)

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

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

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ț?

(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?

(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?

(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?

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

(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.