- #Download firefox 45.0 esr Patch
- #Download firefox 45.0 esr full
- #Download firefox 45.0 esr code
- #Download firefox 45.0 esr windows
Yes, in case you wonder all branches used mozharness from mozilla-central at this time.
#Download firefox 45.0 esr full
Instead those branches got smaller updates for the harness so that they had full support for our latest mozharness script on mozilla-central. Due to backport complexity for older branches I decided to not land packages for Firefox 44.0, 43.0, and 38ESR. Those got landed for Firefox 46.0 on mozilla-central and then backported to Firefox 45.0 which also became our new ESR release. To achieve that I first had to convert all three different modules (harness, puppeteer, tests) to individual Python packages. The move itself was easy but keeping backward compatibility with mozmill-ci and other Firefox branches down to mozilla-esr38 was a lot of work. And with the Taskcluster task as mentioned above it’s even easier to spot those regressors on mozilla-inbound.
#Download firefox 45.0 esr code
It means that our test code including the harness and Firefox Puppeteer is in sync with changes to Firefox now and regressions caused by ui changes should be very seldom. The biggest change for us this quarter was the move of the Firefox UI tests from our external Github repository to mozilla-central. This was possible because the minidump_stackwalk binary can automatically detect the appropriate symbols for nightly and release builds ( bug 1243684) Removing hard requirement for the –symbols-url parameter to let mozcrash analyze the crash.Refactoring of download_unzip() method to allow support of ZipFile and TarFile instead of external commands ( bug 1237706).Fix to always copy the log files to the upload folder even in case of early aborts, e.g.Other Mozharness specific changes are the following ones: If you are interested in the results you can have a look at Treeherder. Due to current Taskcluster limitations this only runs for Linu圆4 debug, but that already helps a lot and I hope that we can increase platform coverage soon. In regards of firefox-ui-tests I was finally able to get a test task added to Taskcluster which will execute our firefox-ui-tests for each check-in and this in e10s and non-e10s mode. No-one noticed that until now because any other testsuite is run on a checkin basis and doesn’t have to rely on the nightly build folders on. Due to binary incompatibilities between those platforms this situation caused complete bustage.
#Download firefox 45.0 esr windows
Means when trying to get the test archives for OS X and Linux always the Windows ones were returned. This work was necessary because without the prefix the file was always overwritten by later build uploads.
#Download firefox 45.0 esr Patch
The most challenging work for me (because I never did a build system patch so far) was indeed prefixing the test_packages.json file which gets uploaded next to any nightly build to. Build System / MozharnessĪfter I had to dig into mozharness to get support for Firefox UI Tests during last quarter I have seen that more work had to be done to fully support tests which utilize Nightly or Release builds of Firefox. When I checked my status reports it’s kinda lot, so I will shorten it a bit and only talk about the really important changes. I'm sure there are other reasons, but to me that was enough to keep things that way instead of following what El Capitan permits.Today is the last day of Q1 2016 which means time to review what I have done during all those last weeks. I've got also 1Password 4 that's still working nicely between all my current browsers: if I switch to Quantum, I have to switch to 1P6 or Enpass and lose that compatibility. It's very likely that I switch back to the latest FF ESR when Chromium drops MacOS 10.11 and Waterfox abandon its pre-Quantum core - as it was the reason I switched from FF to WTF. My current main browser is Chromium, my second choice is Waterfox. maff files to be the best and lightest way to store web pages, I continue storing new pages this way - I think I've got years in front of me before changing computer to something that won't support FF52 ESR in some way (even if at some point it might be through a virtual machine). maff files stored everywhere and it's absolutely out of the question for me to spend hours converting them, so the easiest and most reliable way to read them is with FF52. I want to point out why it's still pertinent to use FF52 ESR - together with other browsers or even the most recent version of FF.įirst of all, I've got a whole lotta.