1204021 - [meta] Identify builds using pvtbuilds infra and determine whether we migrate, create new etc.

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Selena Deckelmann :selenamarie :selena]

I hear that pvtbuilds* is going away sometime in November!

Which builds are we talking about specifically? I'll use this bug as the launching point for: 

* Answering whether we need all those builds going forward
* Figuring out what features / things we need in TaskCluster, or a new TaskCluster service to support (some additional security for artifacts seems likely)
* Sorting out who is going to make the new tasks
* Turning those builds off in buildbot

Comment 1

[Chris AtLee [:catlee]]

All buildbot based B2G builds upload some artifacts to pvtbuilds:
* emulators
* flame-kk
* nexus-4, nexus-5-l
* dolphin-512

The requirement for auth depends on the exact device. Some are simply behind HTTPS + basic auth that requires valid LDAP credentials. Other devices are more restricted because they contain proprietary binaries, so require the user to be a member of a certain LDAP group to access the artifacts.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: b2g builder list

Here's a list of b2g jobs on buildbot sorted into three bins - 
* b2g is the b2g forks of gecko
* main is m-c, m-i, fx-team and the Firefox release branches
* other is the 'rentable' branches

It's generated from a build master (so excludes any tests we might run on buildbot jobs). The master_config.json had this to disable unrelated builders:
  "release_branches": [],
  "mobile_release_branches": [],
  "thunderbird_release_branches": [],
  "limit_branches": [],
  "limit_mobile_branches": [],
  "limit_tb_branches": [],
  "limit_projects": [],
then braindump/buildbot-related/builder_list.py is run. A little post-processing yields the three bins, and removes the buildbot factory.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Also these builds on try:
OS X Mulet try build
Win32 Mulet try build
b2g_try_emulator-debug_dep
b2g_try_emulator_dep
b2g_try_linux64-b2g-haz_dep
b2g_try_macosx64_gecko build
b2g_try_macosx64_gecko-debug build
b2g_try_win32_gecko build
b2g_try_win32_gecko-debug build
builder_list.py master.cfg
graphene_try_linux64 build
graphene_try_macosx64 build
graphene_try_win64 build
horizon_try_linux64 build
horizon_try_macosx64 build
horizon_try_win64 build

You need to hack up buildbot-configs/mozilla/try_localconfig.py in a try master to get that.

Comment 4

[Selena Deckelmann :selenamarie :selena]

Hi Dylan,

We need some help identifying which builds we need to migrate over and provide private artifacts. Lists are in the comments and in the attachment to this bug.

Comment 5

[Dylan Oliver [:doliver]]

Ok, taking a look...

Comment 6

[Selena Deckelmann :selenamarie :selena]

I'm going to plan for addressing these builds based on the feedback at https://public.etherpad-mozilla.org/p/b2g-build-audit

We need to start work on this now to help other teams plan. If it turns out we need other builds, we'll address those, of course. 

b2g (27): b2g forks of gecko
**   b2g_mozilla-b2g37_v2_2_emulator_dep
**   b2g_mozilla-b2g37_v2_2_emulator-debug_dep
**   b2g_mozilla-b2g37_v2_2_flame-kk_nightly
**   b2g_mozilla-b2g37_v2_2_flame-kk_eng_dep
**   b2g_mozilla-b2g37_v2_2_flame-kk_eng_nightly
**   b2g_mozilla-b2g37_v2_2_flame-kk_eng-debug_periodic
**   b2g_mozilla-b2g37_v2_2r_emulator-l_dep
**   b2g_mozilla-b2g37_v2_2r_emulator-l-debug_periodic
**   b2g_mozilla-b2g37_v2_2r_flame-kk_periodic
**   b2g_mozilla-b2g37_v2_2r_flame-kk_nightly
**   b2g_mozilla-b2g37_v2_2r_flame-kk_eng_dep
**   b2g_mozilla-b2g37_v2_2r_flame-kk_eng_nightly

main (76):  m-c, m-i, fx-team and the Firefox release branches
**b2g_b2g-inbound_flame-kk_eng-debug_periodic
**b2g_mozilla-inbound_flame-kk_eng-debug_periodic


other (126):  the 'rentable' branches, Other than PINE, the other project branches are not in use for b2g
**   b2g_pine_emulator_dep
**   b2g_pine_emulator-debug_dep
**   b2g_pine_flame-kk_periodic
**   b2g_pine_flame-kk_eng_dep
**   b2g_pine_flame-kk_eng-debug_periodic
**   b2g_pine_linux64-b2g-haz_dep
**   OS X Mulet pine build
**   b2g_pine_macosx64_gecko build
**   b2g_pine_macosx64_gecko-debug build
**   b2g_pine_nexus-4_periodic
**   b2g_pine_nexus-4_eng_periodic
**   b2g_pine_nexus-5-l_periodic
**   b2g_pine_nexus-5-l_eng_periodic
**   Win32 Mulet pine build
**   b2g_pine_win32_gecko build
**   b2g_pine_win32_gecko-debug build


Also these builds on try:
**   OS X Mulet try build
**   Win32 Mulet try build
**   b2g_try_emulator-debug_dep
**   b2g_try_emulator_dep

Comment 7

[Josh Cheng [:josh]]

Hi Selena, Hi Dylan,

Currently we do not actively do daily smoke test for 2.2 as there is no partner using it instead of 2.2r for RedTai.
Base on current situation I would say we just need to retain 2.2r but not 2.2
**   b2g_mozilla-b2g37_v2_2r_emulator-l_dep
**   b2g_mozilla-b2g37_v2_2r_emulator-l-debug_periodic
**   b2g_mozilla-b2g37_v2_2r_flame-kk_periodic
**   b2g_mozilla-b2g37_v2_2r_flame-kk_nightly
**   b2g_mozilla-b2g37_v2_2r_flame-kk_eng_dep
**   b2g_mozilla-b2g37_v2_2r_flame-kk_eng_nightly

However I am not sure whether there will be any partner want to launch device on 2.2 and we need to enable it again.
The further question would be how long do we need to maintain a release and build once it has been CCed?

Comment 8

[Josh Cheng [:josh]]

We also need following builds:

==  b2g forks of gecko ==
**   b2g_mozilla-b2g37_v2_2r_linux64-b2g-haz_dep
**   b2g_mozilla-b2g37_v2_2r_linux64_gecko build
**   b2g_mozilla-b2g37_v2_2r_linux64_gecko-debug build

== m-c, m-i, fx-team and the Firefox release branches ==
** b2g_b2g-inbound_emulator_dep
** b2g_b2g-inbound_emulator-debug_dep
** b2g_b2g-inbound_flame-kk_periodic
** b2g_b2g-inbound_flame-kk_eng_dep
** b2g_b2g-inbound_flame-kk_eng-debug_periodic
** b2g_b2g-inbound_linux64-b2g-haz_dep
** OS X Mulet b2g-inbound build
** b2g_b2g-inbound_macosx64_gecko build
** b2g_b2g-inbound_macosx64_gecko-debug build
** Win32 Mulet b2g-inbound build
** b2g_b2g-inbound_win32_gecko build
** b2g_b2g-inbound_win32_gecko-debug build
** b2g_mozilla-inbound_emulator_dep
** b2g_mozilla-inbound_emulator-debug_dep
** b2g_mozilla-inbound_flame-kk_periodic
** b2g_mozilla-inbound_flame-kk_eng_dep
** b2g_mozilla-inbound_flame-kk_eng-debug_periodic
** b2g_mozilla-inbound_linux64-b2g-haz_dep
** OS X Mulet mozilla-inbound build
** b2g_mozilla-inbound_macosx64_gecko build
** b2g_mozilla-inbound_macosx64_gecko-debug build
** Win32 Mulet mozilla-inbound build
** b2g_mozilla-inbound_win32_gecko build
** b2g_mozilla-inbound_win32_gecko-debug build
** b2g_mozilla-central_emulator_dep
** b2g_mozilla-central_emulator_nightly
** b2g_mozilla-central_emulator-debug_dep
** b2g_mozilla-central_emulator-debug_nightly
** b2g_mozilla-central_flame-kk_periodic
** b2g_mozilla-central_flame-kk_nightly
** b2g_mozilla-central_flame-kk_eng_dep
** b2g_mozilla-central_flame-kk_eng_nightly
** b2g_mozilla-central_flame-kk_eng-debug_periodic
** b2g_mozilla-central_linux64-b2g-haz_dep
** OS X Mulet mozilla-central build
** OS X Mulet mozilla-central nightly
** b2g_mozilla-central_macosx64_gecko build
** b2g_mozilla-central_macosx64_gecko nightly
** b2g_mozilla-central_macosx64_gecko-debug build
** Win32 Mulet mozilla-central build
** Win32 Mulet mozilla-central nightly
** b2g_mozilla-central_win32_gecko build
** b2g_mozilla-central_win32_gecko nightly
** b2g_mozilla-central_win32_gecko-debug build
== Also these builds on try ==
**   OS X Mulet try build
**   Win32 Mulet try build
**   b2g_try_emulator-debug_dep
**   b2g_try_emulator_dep
**   b2g_try_linux64-b2g-haz_dep
**   b2g_try_macosx64_gecko build
**   b2g_try_macosx64_gecko-debug build
**   b2g_try_win32_gecko build
**   b2g_try_win32_gecko-debug build
**   builder_list.py master.cfg

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Adding a bug to remove nexus 4 (not to be confused with nexus 4-kk).

Comment 10

[Selena Deckelmann :selenamarie :selena]

Mahe,catlee - do you know if we still need any builds to be written to pvtbuilds storage? IT is wanting to turn this off.

Comment 11

[Mahendra Potharaju [:mahe]]

Hey Selena, No. We don't need these builds any longer. You can turn them off. Thanks for checking.

Comment 12

[Chris AtLee [:catlee]]

no, I don't think any of our builds need to upload there any more.

Comment 13

[Greg Cox [:gcox]]

pvtbuilds2.dmz.scl3 is still showing new activity in:

/mnt/pvt_builds/fuzzing/tinderbox-builds/idle-win64-rev2
/mnt/pvt_builds/fuzzing/tinderbox-builds/idle-macosx64-lion
/mnt/pvt_builds/fuzzing/tinderbox-builds/idle-mock

Is that bug 1224333, or something else?

Comment 14

[Greg Cox [:gcox]]

After bug 1224333 went WONTFIX, this bug lost all blockers.  After checking with :gkw, and seeing no activity on the host, I'm going to proceed on a slow-roll decom (meaning, we'll power it off and wait for a good while to make sure nobody notices) of pvtbuilds2.dmz.scl3.

Comment 15

[Greg Cox [:gcox]]

Ran the decom checklist on pvtbuilds2.dmz.scl3.  Closing this up, will file some ancillary infra bugs for other cleanup, but, this is effectively done.