This is a bug for tracking commits to Thunderbird repositories related to the Firefox CI migration.

For this bug, please use the Phabricator/Lando workflow.

This is a port of D14198 for Thunderbird. Using the hardcoded taskcluster.net
hostname is not supported on Firefox-CI.

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/2b2791f094a6
Port bug 1492664: Use {artifact-reference: ..} for symbol uploads. r=darktrojan,tomprince
https://hg.mozilla.org/comm-central/rev/a3bc2a8807db
[firefox-ci] Switch to using aws-provider workers; r=rjl
https://hg.mozilla.org/comm-central/rev/9b8b03b90835
[firefox-ci] Switch thunderbird to gcp scriptworkers; r=mtabara

Comment on attachment 9107561 [details]
Bug 1595153 - [firefox-ci] Switch to using aws-provider workers;

[Request applies to all patches associated with this bug]
These changes look good so far on comm-central. They will need uplifting to beta and esr68 as well.

Comment on attachment 9107561 [details]
Bug 1595153 - [firefox-ci] Switch to using aws-provider workers;

Sure. Maybe wait with beta until TB 71 beta 3 is out the door.

Whatever build# that was for beta 3 had to be canceled because Shipit is being pointed at the new infrastructure and there wasn't a way to continue. We will have to start a new build Monday.

This is a port of D50357 for Thunderbird.

This is a port of D52456 for Thunderbird.

Right now Thunderbird builds won't work because of a problem with the way toolchain tasks are set up.

At the moment, all of the toolchains are just references to the kind definitions in Firefox's tree. The problem is that at least a couple of those toolchain builds are using worker types that aren't set up for comm-* repos.

Specifically, clang uses b-linux-xlarge and b-linux-large which resolve to *comm-X/b-linux-large and *comm-X/b-linux-xlarge.

Those aren't defined in ci-configuration/worker-pools.yml though, so clang never builds.

I'm thinking an easy fix might be to change the alias for b-linux:

workers:
    aliases:
        b-linux.*:
            provisioner: comm-{level}
            implementation: docker-worker
           os: linux
-           worker-type: '{alias}'
+           worker-type: b-linux

That should work.. I am not sure about the ramifications of trying to build clang on a smaller image though.
These failed on try-comm-central as well so I will set up a test build and see how well it works.

Any other suggestions?

We can duplicate the worker gecko-b-linux large worker types to comm.

The Clang toolchain builds use large and xlarge build workers.
Configuring them for Thunderbird builds as suggested.

Sorry to interfere here, but I'd like to maintain C-C in a buildable state since M-C changes are being merged. I trust there is no issue with backing out one line later.

(In reply to Rob Lemley [:rjl] from comment #13)

Created attachment 9107714 [details]
Bug 1595153 - Add large and xlarge b-linux workers to comm provisioners. r?callek

The Clang toolchain builds use large and xlarge build workers.
Configuring them for Thunderbird builds as suggested.

Did we miss these in the migration? Where are/were they used? -- Can this wait until Monday to deploy/fix?

We seem to be OK with the bandaid landed in comment #15.

(In reply to Justin Wood (:Callek) from comment #17)

Did we miss these in the migration? Where are/were they used? -- Can this wait until Monday to deploy/fix?

As Jörg states, he's landed my bandaid, so yes Monday is fine. That's the expectation Tom gave me when I talked to him last night.

These are used only when building the Clang toolchains. Thunderbird uses a loader for toolchains that uses the same kind configs as Firefox. So if you look in comm-central for these workers being used, you don't see them. Perfectly understandable why this didn't get caught earlier. In hindsight, I should have been running try jobs a lot earlier than I did because by the time I realized that Clang wasn't building due to no configured workers being available it was already quite late.

The bandaid I came up with does work. It just aliases the larger instance names to b-linux so the jobs run. However it takes around 70 minutes to compile Clang9 on the smaller instances, whereas looking at the same build jobs that ran for Firefox over the weekend it runs in about 20 minutes.

The time isn't such a big deal IMHO. (Jörg may disagree, he's the one that has to sit there and wait for toolchains to build when they get updated by the build team.) I'm more concerned about the possibility a Clang update that doesn't compile on the smaller instance.

I'm looking at this thinking to myself that it's unreasonable to set up worker instances for what amounts to maybe 10 or so build jobs across the Thunderbird repos in a month.

I'll look for you in IRC tomorrow (Monday).

Tooltool changes for Firefox CI.

This is the right patch for comm-central. The extra-config piece isn't needed now.

TB 71 beta 3:
https://hg.mozilla.org/releases/comm-beta/rev/a499bbe26a5e2ff15b8b8e381512488668517bb4
https://hg.mozilla.org/releases/comm-beta/rev/b688e3f9c08f4cb656f505cab324373dc1797770
https://hg.mozilla.org/releases/comm-beta/rev/44441141040254f8c5576a90bf01477e6f8029b6
https://hg.mozilla.org/releases/comm-beta/rev/04f377118bacd54683eafda57e62f0e21dfdaf66
https://hg.mozilla.org/releases/comm-beta/rev/2da93c04ac9b0490a98eb1eaeed0076a437c9bf1

TB 68.3.0 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/1eafd4139298759bbdcb914fde7446cd0bd2105f
https://hg.mozilla.org/releases/comm-esr68/rev/25df10a02874e61ad9a6040dfb884849069cd12c
https://hg.mozilla.org/releases/comm-esr68/rev/e9c6aac65488ebd3a2dc8799a92de50a82919ba4
https://hg.mozilla.org/releases/comm-esr68/rev/67bb4c4872d2c2c4a099c66e6812d3a923577041
https://hg.mozilla.org/releases/comm-esr68/rev/669aa413ec10e24bb2de0a105b25f6d05f3f40ec
For ESR I took the beta changeset. The second one needed rebasing.