Once bug 1534533 is fixed, we can stop building geckodriver as part of the build job. Given that test jobs rely on the geckodriver binary as part of the common tests package, those will have to be updated first to be dependent on the geckodriver-repack job instead.

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=geckodriver-repack

Note that right now this job only runs for Nightly builds of Firefox, which will also change with bug 1534533. By then we will built it for every commit, but only sign the binaries for Nightly builds of Firefox.

Does geckodriver-repack also build? In that case it’s somewhat
misleadingly named.

No, the repack job doesn't build, but I don't see the naming as problematic right now.

I’m confused, where will geckodriver be built then?

Sorry the summary from bug 1534533 was a bit misleading. The build would happen in the toolchain task, if we agree on that. For a while we will run this job in parallel, and then we can remove this repack job.

How would this affect local developers who may well need geckodriver for running tests? Or is this just about CI?

Note that building geckodriver is relatively quick since most of the deps are also used for gecko, so it's not going to be a huge win on time/cost. But not nothing of course.

(In reply to James Graham [:jgraham] from comment #5)

How would this affect local developers who may well need geckodriver for running tests? Or is this just about CI?

I think that it would affect them when they are doing an artifact build. In such a case we should get the binary from the toolchain job and not the build job.

One issue is that the version built as part of the build in automation is huge (>50MB), which bloats the test archives and makes them slower to compress, transfer, and unpack.

Use fetches in tests to pull in the geckodriver binaries from the toolchain
builds.

Adjust paths in web-platform tests to refer to fetches

Chris, we are still blocked on bug 1577110. Maybe you can have a look at this? I'm more than happy to get rid of the build job and only have the toolchain jobs, but signing must work for us to be able to ship geckodriver to our users.

In regards of the notarization problem (bug 1588081), is there anything which is different between the normal builds and toolchain builds? If yes, and it would introduce a regression we won't actually be able to release from toolchain builds.

Now with bug 1577110 fixed we should still wait a bit of time to allow consumers to adjust their code for the new location of the geckodriver binary.

James, where is the work for wptrunner tracked?

https://bugzilla.mozilla.org/show_bug.cgi?id=1636907

Thanks. Marking as dependency then.

Chris, is the old patch on this bug still relevant or made obsolete by your new patch or other patches?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #15)

Chris, is the old patch on this bug still relevant or made obsolete by your new patch or other patches?

The part around fetches is obsolete. The part that disables building geckodriver in CI is still valid. I'll update the patch.

https://hg.mozilla.org/mozilla-central/rev/d254d3838877

https://hg.mozilla.org/mozilla-central/rev/0d42fb2a6fe5