Closed Bug 948744 Opened 8 years ago Closed 8 years ago

b2g wasabi build for 1.3

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(b2g-v1.3 fixed, b2g-v1.4 fixed)

RESOLVED FIXED
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.4 --- fixed

People

(Reporter: aki, Assigned: jlund)

References

Details

Attachments

(6 files, 2 obsolete files)

Filing, since bug 909226 got morphed into a one-off 1.2 build bug.
Assignee: nobody → jlund
hmm, looks like I am getting sync errors when running checkout-sources action:
command: script -q -c "/builds/slave/b2g_m-cen_wsb_dep-000000000000/build/repo sync"

log:
10:36:40     INFO - Fetching projects:   5% (5/91)  Fetching project platform/vendor/qcom/msm8960
10:36:41     INFO -  fatal: remote error: FATAL: R any external/caf/platform/vendor/qcom/msm8960 gitweb DENIED by fallthru
10:36:41     INFO -  (or you mis-spelled the reponame)

these seem to be coming from the manifest: https://github.com/mozilla-b2g/b2g-manifest/blob/master/wasabi.xml#L108 <- under wasabi-specific things
Depends on: 958696
I believe I have wasabi builds running in our buildbot staging environment through my dev machine.

The log here is what I have been able to run:
http://people.mozilla.org/~jlund/b2g_wasabi-110114.txt

There are some errors but I believe those to be upload related steps. Which is to be predicted as my tested slave is using staging keys while trying to push to a production expecting location.

My unknowns:
1) do we want nightlies of this? I have them enabled on my patches but I just wanted to assert.
2) in terms of locales I am guessing we want all locales? As it stands, all locales are enabled
3) Do we want to send uploads to /pvt/mozilla.org/b2gotoro/tinderbox-builds if we are not running a nightly build? As in, should 'wasabi' be in this list -> http://mxr.mozilla.org/build/source/mozharness/configs/b2g/releng-private-updates.py#24

Patches incoming. :)
Attachment #8358868 - Flags: review?(aki)
Attachment #8358870 - Flags: review?(aki)
Attachment #8358871 - Flags: review?(ryanvm)
> My unknowns:
> 1) do we want nightlies of this? I have them enabled on my patches but I
> just wanted to assert.
> 2) in terms of locales I am guessing we want all locales? As it stands, all
> locales are enabled
> 3) Do we want to send uploads to /pvt/mozilla.org/b2gotoro/tinderbox-builds

4th unknown:
4) do we need 'engineering' builds of this?
Comment on attachment 8358871 [details] [diff] [review]
948744_wasabi_1.3_builds-tbpl-100114.diff

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

r=me with the changes noted

::: js/Config.js
@@ +258,5 @@
>                             "Unagi Device Image Build (Engineering)",
>                             "Unagi Device Image Nightly",
>                             "Unagi Device Image Nightly (Engineering)"],
> +    "Wasabi Device Image": ["Wasabi Device Image Build",
> +                           "Wasabi Device Image Nightly"],

One more space on the second line.

@@ +387,5 @@
>      "Unagi Device Image Build (Engineering)": "Be",
>      "Unagi Device Image Nightly": "N",
>      "Unagi Device Image Nightly (Engineering)": "Ne",
> +    "Wasabi Device Image Build": "B",
> +    "Wasabi Device Image Nightly": "N",

You need a "Wasabi Device Image": "Wasabi" line above these two for the grouping to work.
Attachment #8358871 - Flags: review?(ryanvm) → review+
Hi,

QA don't need wasabi nightly at this moment since the phone is not for shipping. Chris(catlee) already shared one build for our internal testing. FYI.
Attachment #8358868 - Flags: review?(aki) → review+
Attachment #8358869 - Flags: review?(aki) → review+
Comment on attachment 8358870 [details] [diff] [review]
948744_wasabi_1.3_builds-bbotcfgs-090114.diff

I think the main (only?) difference between releng-private-updates.py and releng-otoro.py is the former allows for updates on nightlies.
Per comment 9, we don't need nightlies, so we probably want to turn them off.

So enable_nightly -> False, and releng-private-updates.py -> releng-otoro.py afaict.

>+# MERGE DAY: wasabi is for B2G 1.3+ only
>+# When gecko29 is on aurora we don't run B2G builds there, but will on beta
>+for _, branch in items_before(BRANCHES, 'gecko_version', 29):
>+        if 'wasabi' in branch['platforms']:
>+                del branch['platforms']['wasabi']

8 spaces -> 4 spaces.

Thanks Jordan!
Attachment #8358870 - Flags: review?(aki) → review+
Thanks for previous review. We no longer require nightlies so I removed some lines and some of my mistakes in last patch are n/a
Attachment #8358871 - Attachment is obsolete: true
Attachment #8359419 - Flags: review?(ryanvm)
Attachment #8359419 - Flags: review?(ryanvm) → review+
using releng-otoro.py, enable_nightly set to False

I will land these patches tonight if r+.

aki, I'm guessing I should land tbpl and m-c patches first? Once m-c patch makes it's way through m-i, I assume it is then that I apply buildbot patches to default? That may be obvious but I just want to assert.
Attachment #8358870 - Attachment is obsolete: true
Attachment #8359421 - Flags: review?(aki)
FYI, you'll need to file a bug to update the production instance of TBPL after you push the TBPL patch (bug 958593 being the most recent instance of such a request). When you push, your patch will show up on http://tbpl-dev.allizom.org/ within 15min or so.
Comment on attachment 8359421 [details] [diff] [review]
948744_wasabi_1.3_builds-bbotcfgs-130114.diff

>+# MERGE DAY: wasabi is for B2G 1.3+ only
>+# When gecko29 is on aurora we don't run B2G builds there, but will on beta
>+for _, branch in items_before(BRANCHES, 'gecko_version', 29):
>+        if 'wasabi' in branch['platforms']:
>+            del branch['platforms']['wasabi']

Four spaces!  The del is good relatively speaking, but the |if 'wasabi'| is 8, so both lines need 4 fewer spaces.
Attachment #8359421 - Flags: review?(aki) → review+
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #13)
> FYI, you'll need to file a bug to update the production instance of TBPL
> after you push the TBPL patch

Perfect, thanks! I'll file now.

This has been pushed to default: https://hg.mozilla.org/webtools/tbpl/rev/1ecf06182684
I'd like to get the TBPL patch for bug 940768 landed before the next push to production as well. If it's OK with you, I'll take care of filing and getting it updated tomorrow.
mozilla-central patch pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/11651cf8335d
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #16)
> I'd like to get the TBPL patch for bug 940768 landed before the next push to
> production as well. If it's OK with you, I'll take care of filing and
> getting it updated tomorrow.

No problemo! Whatever works best for you. I won't file a request for my wasabi patch to be merged in production. Leaving it in your hands. Thanks for getting it out in the wild :)
Whiteboard: [leave open]
Depends on: 959552
(In reply to Jordan Lund (:jlund) from comment #15)
> This has been pushed to default:
> https://hg.mozilla.org/webtools/tbpl/rev/1ecf06182684

In production :)
Attachment #8359421 - Flags: checked-in+
Attachment #8358869 - Flags: checked-in+
Can't run these on try, anyway.
Attachment #8360039 - Flags: review?(jlund)
Attachment #8360039 - Flags: review?(jlund) → review+
something is in production
Now with less bustage on Aurora. AFAICT, I made all the needed aurora/v1.3 changes to config.json. Would be nice to have a second set of eyes look at it, though.


https://hg.mozilla.org/releases/mozilla-aurora/rev/ae2c436cecdc
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #25)
> Now with less bustage on Aurora. AFAICT, I made all the needed aurora/v1.3
> changes to config.json. Would be nice to have a second set of eyes look at
> it, though.

Shoot, I should have realized I'd need to land the patches on aurora too. Thanks for fixing my mistake. /me learns and won't let it happen again.
FYI, these builds are also running on mozilla-inbound and fx-team, which I don't believe was the intent.
Looks like I enabled this on too many branches. Reverting to the style of explicitness (and 4 spaces!) with only the given branches for now.
Attachment #8360850 - Flags: review?(aki)
Attachment #8360850 - Flags: review?(aki) → review+
pushed latest buildbot-config patch to default: https://hg.mozilla.org/build/buildbot-configs/rev/1747d962f457
Attachment #8360850 - Flags: checked-in+
something is in production
Whiteboard: [leave open]
These builds are running green on the appropriate branches. Going to mark this as resolved.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.