Re: Deprecation notice - change to Treeherder's jobdetail API

[Nicholas Alexander]

Hello Sarah, others,

On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements  wrote:

> Hello,
>
> As part of maintenance work and performance improvements to Treeherder,
> we're making changes to some of the data that's stored in our database. On 
> *April
> 30th*, we will no longer be retrieving uploaded artifacts for jobs and
> storing them in the JobDetail table.
>
> Uploaded artifacts can be retrieved via a taskcluster API, with the
> appropriate rootUrl, taskId and runId. TaskId and runId (synonymous with
> retryId in Treeherder) can be surfaced from any of our /jobs/ API's. See
> this
> 
> for implementation details.
>
> We're also planning to deprecate the parsing and storage of TinderboxPrint
> log lines in the JobDetail table. They'll no longer be shown in
> Treeherder's job detail panel but you can still read them in the raw logs
> via the log-viewer.
>
> If you have any questions or concerns (or need a longer timeline to make
> changes that rely on this data), don't hesitate to reach out.
>

I have worked with both of these APIs and been frustrated with them (and
filed tickets that are now being closed), so I'm pleased to see changes in
this area.  However, I have some questions.

Does the TH UI that exposes artifacts change as part of this?  I.e., does
it get harder to find the package produced by a build job?

I don't see any slated replacement for print lines.  A great deal of useful
information is summarized in these lines (e.g., we dump
libxul/classes.dex/and APK sizes using this mechanism -- or at least we
did).  What's happening here?

Best,
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Prototype: ETP Cookie Purging

[Johann Hofmann]

In bug 1628743  I
plan to enable ETP cookie purging by default on Nightly only, affecting
both desktop and mobile.

In short, ETP cookie purging is an attempt to protect against first-party
redirect (“bounce”) trackers by periodically clearing their site data. To
that effect, any site that is on our list of known trackers and did not
receive user interaction (including scrolling) in the last 30 days will
have all its cookies and other storage cleared during idle daily.

A similar technique is already being shipped in Safari as part of ITP
.
Standardization of such a mechanism is currently being discussed in the
Privacy CG
. Our
implementation is likely to be altered based on the outcome of that
discussion.

Our plan is to let this bake for at least the 77 cycle and evaluate for
bugs and potential breakage before we make a decision to ship in 78, or
later.

The preference to control this is privacy.purge_trackers.enabled.

Should you notice strange website behavior on Nightly that revolves around
state management (e.g. getting logged out of a site too frequently), please
file a bug blocking bug 1594226
. We’re happy to
investigate further.

Please let me know if you have any questions or concerns.

Thanks,

Johann
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster compilers available in bootstrap

[Mike Conley]

Yes, this is wonderful, thank you so much! Improvements to build times are
a force-multiplier. 5%-15% improvements in our build times is no joke!

On Thu, 9 Apr 2020 at 13:09, Botond Ballo  wrote:

> Thanks, compile time improvements are always good news!
>
> Out of curiosity, does this impact builds targeting Android on Linux or
> Windows?
>
> Thanks,
> Botond
>
> On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
> >
> > As of bug 1326486, our clang toolchains for Linux and Windows are built
> > with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
> >
> > Under optimal conditions (Spidermonkey build, touch mfbt) I've seen
> 10-15%
> > compile time improvements locally, but in more common scenarios the gains
> > will be diluted by other parts of the system. Perfherder measured 5-9%
> > improvements in CI.
> >
> > To pick up a new compiler: after the next time you update your tree, run
> > `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> > --from-build linux64-clang`, or on Windows replace the last part with
> > `win64-clang-cl`.
> >
> > Happy compiling!
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster compilers available in bootstrap

[David Major]

Yes, I believe so.

On Thu, Apr 9, 2020 at 1:09 PM Botond Ballo  wrote:

> Thanks, compile time improvements are always good news!
>
> Out of curiosity, does this impact builds targeting Android on Linux or
> Windows?
>
> Thanks,
> Botond
>
> On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
> >
> > As of bug 1326486, our clang toolchains for Linux and Windows are built
> > with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
> >
> > Under optimal conditions (Spidermonkey build, touch mfbt) I've seen
> 10-15%
> > compile time improvements locally, but in more common scenarios the gains
> > will be diluted by other parts of the system. Perfherder measured 5-9%
> > improvements in CI.
> >
> > To pick up a new compiler: after the next time you update your tree, run
> > `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> > --from-build linux64-clang`, or on Windows replace the last part with
> > `win64-clang-cl`.
> >
> > Happy compiling!
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster compilers available in bootstrap

[Botond Ballo]

Thanks, compile time improvements are always good news!

Out of curiosity, does this impact builds targeting Android on Linux or Windows?

Thanks,
Botond

On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
>
> As of bug 1326486, our clang toolchains for Linux and Windows are built
> with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
>
> Under optimal conditions (Spidermonkey build, touch mfbt) I've seen 10-15%
> compile time improvements locally, but in more common scenarios the gains
> will be diluted by other parts of the system. Perfherder measured 5-9%
> improvements in CI.
>
> To pick up a new compiler: after the next time you update your tree, run
> `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> --from-build linux64-clang`, or on Windows replace the last part with
> `win64-clang-cl`.
>
> Happy compiling!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Faster compilers available in bootstrap

[David Major]

As of bug 1326486, our clang toolchains for Linux and Windows are built
with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)

Under optimal conditions (Spidermonkey build, touch mfbt) I've seen 10-15%
compile time improvements locally, but in more common scenarios the gains
will be diluted by other parts of the system. Perfherder measured 5-9%
improvements in CI.

To pick up a new compiler: after the next time you update your tree, run
`./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
--from-build linux64-clang`, or on Windows replace the last part with
`win64-clang-cl`.

Happy compiling!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

`mach test --headless` now supports xpcshell-tests

[Matthew N.]

On the next merge to mozilla-central, the `mach test --headless` command
will no longer give an error on directories containing xpcshell tests
 (along with other
suites already supporting --headless). Prior to this enhancement the
command would fail as soon as an xpcshell test was encountered since that
harness didn't support the argument. This required running mach multiple
times in order to execute all tests for a component. Now you no longer have
to worry about whether the tests you execute have a mix of xpcshell and
mochitest flavors when deciding whether to use --headless.

This also means that `mach xpcshell-test --headless` doesn't error, but
that's probably not too interesting for most developers on its own as the
xpcshell test harness already supported running specific tests in headless
mode with the `headless = true` xpcshell.ini annotation
.
The --headless command line argument has the same behavior as that
annotation
,
it's not a no-op, so it may change some behaviour in tests involving
rendering though those are likely very rare in this suite. Also note that
this configuration isn't run in automation so it's possible some tests will
fail under it but don't without --headless so you may want to run a test
without the argument if you're seeing an unusual failure that doesn't
appear in automation. In that case you could opt the test out of headless
mode with `headless = false` in the manifest.

Thanks to Geoff Brown for the quick review.

Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform