Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 3 dagen 15 uur geleden

Chris AtLee: Taskcluster migration update, the sequel

za, 03/03/2018 - 13:26
Firefox, now 100% buildbot-free!

First, the good news - Developer Edition 60.0b1 will be the first release in nearly 10 years done without using buildbot. This is an amazing milestone, and I'm incredibly proud of everybody who has contributed to make this possible!

Long time, no update

How did we get here? It's been, uh, almost 6 months since I last posted an update about our migration to Taskcluster.

In my last update, I described our plans for the end of 2017...

We're on track to ship builds produced in Taskcluster as part of the 56.0 release scheduled for late September. After that the only Firefox builds being produced by buildbot will be for ESR52. Meanwhile, we've started tackling the remaining parts of release automation. We prioritized getting nightly and CI builds migrated to Taskcluster, however, there are still parts of the release process still implemented in Buildbot. We're aiming to have release automation completely migrated off of buildbot by the end of the year. We've already seen many benefits from migrating CI to Taskcluster, and migrating the release process will realize many of those same benefits. How'd we do?

We're past the end of 2017, so how are we doing?

Well, we successfully shipped 56.0 with builds produced in Taskcluster. Our big Firefox Quantum release (57.0), was also shipped with builds produced by Taskcluster.

(side note: 57 had the most complex update scenarios we've ever had to support for Firefox...a subject for another post!)

Release scheduling

Post-56.0, our release process was using Taskcluster exclusively for producing the initial builds, and all the release process scheduling. We were still using Buildbot for many of the post-build tasks, like l10n repacks, publishing updates, pushing files to S3, etc. Once again we relied on the buildbot bridge to allow us to integrate existing buildbot components with the newer taskcluster pipeline. I learned from Kim Moir that this is a great example of the strangler pattern.

In the fall of 2017, we decided to begin migrating all of the scheduling logic for release automation into taskcluster using the in-tree taskgraph scheduling system. We did this for a few reasons...

  1. Having the release scheduling logic ride the trains is much more maintainable. Previous to this we had an externally defined release pipeline in our releasetasks repo. It was hard to keep this repository in sync with changes required for beta/release and ESR branches.

  2. More importantly, having the release scheduling logic in-tree meant that we could then rely on chain-of-trust to verify artifacts produced by the release pipeline.

  3. We felt that having the complete release pipeline defined in taskcluster would make it easier for us to tackle the remaining buildbot bridge tasks in parallel.

We hit this milestone in the 58 cycle. Starting with 58.0b3, Firefox and Fennec releases were completely scheduled using the in-tree taskgraph generation. We also migrated over the l10n repacks at the same time, removing a longstanding source of problems where repacks would fail when we first got to beta due to environmental differences between taskcluster and buildbot.

No-BBB Releases

Still, as of 58, much of release automation still ran on buildbot, even if Taskcluster was doing all the scheduling.

Since December, we've been working on removing these last few pieces of buildbot from the release process. Progress was initially a bit slow, given Austin and Christmas, but we've been hard at work in the new year.

That brings us to today.

We've moved uptake monitoring, update verify (and made it 2x faster too!), update submission, final verify, bouncer submission, version bumping and tagging, balrog submission all to run in Taskcluster via various kinds of scriptworkers.

As I mentioned above, DevEdition 60.0b1 will be the first release in nearly 10 years done without using buildbot. The rest of the 60 release cycle will follow suit, and once 60 hits the release channel, only ESR52 will remain on buildbot!

Categorieën: Mozilla-nl planet

K Lars Lohn: Things Gateway - Part 5

vr, 02/03/2018 - 18:00
In Part 4 of this series, I showed how to link the Things Gateway with a quartet of Philips Hue bulbs via the Hue Bridge.  There are advantages and disadvantages to using the Hue Bridge.  On the plus side, the Hue Bridge enables the mobile device app, a mature controller for Hue lights with plenty of bells and whistles.  On the downside, the Hue Bridge is an Internet capable device, and I'm just not sure I can trust that.

My experience shows that if you purchase a Hue bulb packaged without a Hue Bridge, you can pair the light directly with a Zigbee adapter.  This means that the light works like any Zigbee compatible bulb.

Purchasing Hue bulbs in a Starter Kit can be a less expensive way to purchase Hue bulbs.  Starter Kits include three or four bulbs along with a Hue Bridge.  However, the bulbs are effectively locked to the Hue Bridge that came in the package.  To use the bulb without the Hue Bridge, the bulbs need liberation. Fortunately, it is not as complicated and perilous as jail breaking a cell phone.  Ironically, Philips sells the tool to do the unlocking disguised as their own remote Hue Dimmer Switch.

Caveat emptor:  If you really want to avoid the Hue Bridge, compare the costs of buying single bulbs versus Starter Kits, factoring in the cost of the Hue Dimmer Switch.  The only way that Starter Kits saved money was when I found them on sale.  At their full price, they are a dubious bargain.

Goal: Get the Things Gateway to control Hue light bulbs without the use of a Hue bridge. Maintain total local control with no component communicating outside to the Internet.
To reproduce everything that I'm doing here today, you'll need these things:

Requirements & Parts List:
ItemWhat's it for?Where I got itThe Raspberry Pi and associated hardware from Part 2 of this series.This is the base platform that we'll be adding ontoFrom Part 2 of this seriesDIGI XStickThis allows the Raspberry Pi to talk the ZigBee protocol - there are several models, make sure you get the XU-Z11 model.The only place that I could find this was Mouser ElectronicsPhilips Hue White & Color Ambiance bulbTo demonstrate use of a Hue bulb without any extra parts or incantationsHome DepotPhilips Hue White & Color Ambiance Starter KitTo demonstrate unlocking Hue bulbs from their associated Hue BridgeAmazonPhilips Hue Dimmer SwitchThe magic key that can unlock Hue bulbsAmazon
Step 1: I'm assuming that we're starting with the Things Gateway configured for the Zigbee adapter.  See Part 2 of this series for instructions.  Remember to update the Zigbee add-on as specified in the instructions.

Step 2: First we're going to just show that we can, with no fuss, use a Philips Hue bulb that was not packaged with a Hue Bridge.
From the Things pane, press the "+" button.
Plug in your Hue light, you should see the bulb detected.  Press "Save" and "Done".
You now have full control of a Hue bulb in the Things Gateway.  You can repeat this step with any Hue bulbs that were purchased without a Hue Bridge.

Step 3:  From this point on, we're only going to deal with liberating Hue bulbs that were purchased in a Starter Kit that included a Hue Bridge.   If you've already set up your Hue lights and Bridge, these instructions will effectively undo that setup.
The first thing that we need to do is unlock the bulbs.  For that, we're going to use the Hue Dimmer Switch.  You'll notice that the instructions for the dimmer switch want you to pair it with the bridge.  Since our goal is to not use the bridge, we're going to ignore the instructions.  Pull the battery tab to get power to the dimmer.  There will be a tiny light in one corner of the ON switch that blinks orange.  This means that it is looking to pair with a Hue Bridge.  You may ignore the blinking light.

We're going to apply power to one of our Hue bulbs.  It should light up warm white in color.  Hold the Hue Dimmer in both hands with thumbs set to press both the ON and OFF buttons at the same time.  Move the dimmer to within four inches of the bulb to be unlocked.  Press and hold the ON and OFF buttons.  After ten seconds, continue holding when the bulb blinks a harsh bluish white light several times and then re-illuminates to a warm white.  Release the buttons.
Repeat this step for each bulb that you want to unlock.  In my case, since my bulbs are so close to each other, I had to ensure that only one bulb was powered at a time.

The Hue Dimmer can factory reset other Zigbee compatible bulbs, like the CREE bulbs and Ikea TRÅDFRI bulbs.  I'll have more on that in a future Ikea focused installment.

Step 4:  To add your newly unlocked Hue bulbs to the Things Gateway, repeat Step 2 for each bulb.  When completed, I had five Hue bulbs ready to color at will.  Now will somebody remind me why I would want lights of all these different colors?
In the next installment, I'm going to integrate TP-Link devices into this circus.
Categorieën: Mozilla-nl planet