FYI: Taskcluster Services Migration

2019-08-12 Thread Dustin Mitchell
*tl;dr:* Taskcluster, the platform supporting Firefox CI, will be moving to
a new hosting environment during the tree-closing window at the end of
September.  This is a major change and upgrade to the platform, but may
cause some bumps along the way.

Taskcluster is in the midst of a few migrations [1], and one of those is
moving to a new hosting environment.  This has a few advantages:
 * Operations will be managed by professionals (cloudops), not developers
(TC team)
 * Administration will be managed by professionals (releng), not developers
(TC team)
 * Hosting will be in a more trusted environment (GCP instead of Heroku)
 * New, faster UI
 * New, faster, more reliable worker-provisioning backend

The downside is that URLs will be changing, likely leaving some dangling
pointers.  We've anticipated some of the most common (such as
https://queue.taskcluster.net/ URLs) and are planning workarounds, but
nonetheless anticipate some dead links for a while following the switch.

Dustin

[1]
https://mana.mozilla.org/wiki/pages/viewpage.action?spaceKey=TAS&title=Migrations
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Planned Taskcluster Migration Upcoming

2019-08-06 Thread Dustin Mitchell
*tl;dr:* Taskcluster, the platform supporting Firefox CI, will be moving to
a new hosting environment during the tree-closing window at the end of
September.  This is a major change and upgrade to the platform, but may
cause some bumps along the way.

Taskcluster is in the midst of a few migrations [1], and one of those is
moving to a new hosting environment.  This has a few advantages:
 * Firefox CI will be handled by dedicated teams, separate from the TC team:
   * Service operations will be managed by cloudops
   * Administration will be managed by releng
   * Workers will be managed by relops
 * Hosting will be in a more trusted environment (GCP instead of Heroku)
 * The services will have a new, faster UI
 * Worker provisioning will be faster and more reliable, and cover more
cloud environments
 * ..lots of other achievements unlocked by shedding 5+ years of legacy

The downside is that URLs will be changing, likely leaving some dangling
pointers.  We've anticipated some of the most common (such as
https://queue.taskcluster.net/ URLs) and are planning workarounds, but
nonetheless anticipate some dead links for a while following the switch.

This work is tracked in bug 1546801 [2].  If you have questions or
concerns, please get in touch with me or anyone on the team, or file a bug
in Taskcluster :: General and we will triage it appropriately.

Dustin

[1]
https://mana.mozilla.org/wiki/pages/viewpage.action?spaceKey=TAS&title=Migrations
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1546801
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Incoming Change: try pushes from before Feb 4 will not start a decision task

2019-03-11 Thread Dustin Mitchell
@tomprince reminds me that it's important to note these changes were
uplifted to the release branches, so pushing release branches to try should
continue to work without any issue.

Dustin

On Mon, Mar 11, 2019 at 6:33 PM Dustin Mitchell  wrote:

> I am in the process of landing
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1526979
> which changes the way we trigger decision tasks to make them more
> predictable and debuggable.
>
> In the process, I landed the necessary in-tree support in
>   https://phabricator.services.mozilla.com/D18288
>   https://phabricator.services.mozilla.com/D18269
> which hit mozilla-central on Feb 4.
>
> I will be changing the configuration for try to use the "new way" this
> Thursday.  Once that is done, try pushes which do not include the in-tree
> support (that is, which are based on a push more than a month old) will
> result in a failed decision task.  The fix is to include the above two
> changes in your try push.
>
> I hope this does not cause too much inconvenience!  If there's some reason
> this change should not take place, please let me know.
>
> Dustin
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Incoming Change: try pushes from before Feb 4 will not start a decision task

2019-03-11 Thread Dustin Mitchell
I am in the process of landing
  https://bugzilla.mozilla.org/show_bug.cgi?id=1526979
which changes the way we trigger decision tasks to make them more
predictable and debuggable.

In the process, I landed the necessary in-tree support in
  https://phabricator.services.mozilla.com/D18288
  https://phabricator.services.mozilla.com/D18269
which hit mozilla-central on Feb 4.

I will be changing the configuration for try to use the "new way" this
Thursday.  Once that is done, try pushes which do not include the in-tree
support (that is, which are based on a push more than a month old) will
result in a failed decision task.  The fix is to include the above two
changes in your try push.

I hope this does not cause too much inconvenience!  If there's some reason
this change should not take place, please let me know.

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


Introducing CI-Admin

2018-08-22 Thread Dustin Mitchell
We have been working on a new approach to configuring the Firefox-CI
installation of Taskcluster to suit Firefox's needs.  If you've ever needed
a scope assigned to a repository, wondered why your project branch wasn't
getting builds, or couldn't figure out what instance type a worker uses,
this is the tool for you.

I'd like to encourage broad familiarity with this system so that it can
become a shared resource.

I've written up an intro at
http://code.v.igoro.us/posts/2018/06/ci-admin.html  I'll also be holding
two "open house" sessions next week, in the TaskclusterPlatform vidyo
room.  I've sent out some invitations, but if you didn't get one, here are
the details:

  Aug 28, 21:00UTC (14:00 PDT)
  Aug 29, 13:00UTC (15:00 CEST)

(and feel free to ping me to be added to the event).

See you there!

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


Re: Firefox Browser performance test

2017-11-17 Thread Dustin Mitchell
Firefox has an extensive performance testing framework, called Talos

https://wiki.mozilla.org/Buildbot/Talos might be a good place to start.

Dustin

2017-11-17 10:02 GMT-05:00  :
> Hello,
>
> I would like to test Firefox browser performance test - using default 
> settings and using customized settings(about:config).
>
> Performance parameters I am looking :
> 1. Time - required to open webpage
> 2. Number of packets transferred between the browser and website - while 
> opening
>the first page of the website on the browser (client side)
> 3. Size of each packet - transferred between the browser and website - while
>opening the first page of the website on the browser (client side).
> 4. Any other method (or parameter) which needs to be considered for 
> performance
>testing.
>
> Can you suggest me any tool or benchmark tool - that will help me.
>
> Waiting for the reply.
>
> Thanks & Regards
>
> Harshad
> ___
> 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: Reviews for in-tree documentation (was: Builds docs on MDN)

2017-10-19 Thread Dustin Mitchell
I think we should question the assumption that writing
source-code-level documentation is a good activity for newcomers to
the codebase.

Documentation is usually best written by someone with a deep
understanding of what is being documented, not by someone new to the
project.  And this documentation is developer-focused, meaning anyone
understanding its content deeply should generally be an experienced
developer.

At the most, I can see using a documentation edit as an exercise in
going through the patch / review / land process for a contributor who
I would then urge on to more substantive tasks (which may also involve
substantive doc updates).

All of which is to say, yes, I'd like to see the numbers on this and I
think we should use those numbers to think carefully about whether the
proposal merits the cost in complexity, implementation time, and
security risk.

Dustin

2017-10-19 13:13 GMT-04:00 Andreas Tolfsen :
> Also sprach Sylvestre Ledru:
>
>> By the way, do we know how many mdn contributions are made on
>> these pages by people who are not regular Firefox developers?  A
>> push in-tree requires permissions, which isn't a small barrier,
>> might impact that (not mentioning the size of the repo).  If this
>> is only a few people, this might not be an issue.
>
>
> I don’t have these numbers, but gps had some thoughts on how
> to potentially allow on-line GitHub editing PRs to m-c for
> below-commit-level-3 changes that you can read more about in the
> other thread [1].  Perhaps that is a way to make drive-by community
> contributions to in-tree documentation easier.
>
> My primary concern is to first fix the papercut of having to channel
> changes to existing in-tree documentation through the same review
> process as regular source code.
>
>  [1]
> https://groups.google.com/d/msg/mozilla.dev.builds/cp4bJ1QJXTE/MQUHhqX-DAAJ
>
> ___
> dev-builds mailing list
> dev-bui...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: ./mach try empty

2017-09-26 Thread Dustin Mitchell
This is awesome, thanks Wes!

Dustin

2017-09-26 16:16 GMT-04:00 KWierso :
> I've recently landed a new way to push things to the tryserver. With `./mach 
> try empty`, mach will just push whatever commits you're working on to try, 
> without prompting you for anything and without scheduling any builds or 
> tests. Once pushed, you can sign in to Treeherder and manually add whatever 
> jobs you'd like via Treeherder's "Add New Jobs" button in the per-push menu.
>
> The tryserver wiki page[1] has a section showing how to manually add jobs to 
> a push, with some pictures, if it's helpful.
>
> You'll need to be on a somewhat recent checkout of mozilla-central, and it 
> wouldn't hurt to run `./mach mercurial-setup --update` again, though I don't 
> believe that's strictly necessary.
>
>
> Enjoy,
> Wes
>
>
>
> 1. 
> https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder
> ___
> 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: ./mach try empty

2017-09-26 Thread Dustin Mitchell
This is awesome, thanks Wes!

Dustin

2017-09-26 16:16 GMT-04:00 KWierso :
> I've recently landed a new way to push things to the tryserver. With `./mach 
> try empty`, mach will just push whatever commits you're working on to try, 
> without prompting you for anything and without scheduling any builds or 
> tests. Once pushed, you can sign in to Treeherder and manually add whatever 
> jobs you'd like via Treeherder's "Add New Jobs" button in the per-push menu.
>
> The tryserver wiki page[1] has a section showing how to manually add jobs to 
> a push, with some pictures, if it's helpful.
>
> You'll need to be on a somewhat recent checkout of mozilla-central, and it 
> wouldn't hurt to run `./mach mercurial-setup --update` again, though I don't 
> believe that's strictly necessary.
>
>
> Enjoy,
> Wes
>
>
>
> 1. 
> https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder
> ___
> 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: Reminder on Try usage and infrastructure resources

2017-09-14 Thread Dustin Mitchell
2017-09-14 18:32 GMT-04:00 Botond Ballo :
> I think "-p all" is still useful for "T pushes" (and it sounds like
> build jobs aren't the main concern resource-wise).

Correct -- all builds are in AWS.

I'd like to steer this away from "What legacy syntax should we use
instead?" and "How should we tweak the legacy try syntax?" to:

 How can we use the modern tryselect functionality to achieve more
precise try pushes?

(tryselect is the task-selection logic behind ./mach try fuzzy)

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


Re: [Sheriffs] Intent to Implement: Remove Treeherder Exclusion Profiles in lieu of Tiers

2017-09-14 Thread Dustin Mitchell
And if there are any unexpected-visible tasks, we stand ready to fix
that either in the tier settings or during Treeherder ingestion.  Let
us know.

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


Re: ./mach try fuzzy: A Try Syntax Alternative

2017-09-03 Thread Dustin Mitchell
2017-09-03 13:51 GMT-04:00 William Lachance :
> There's also the "retrigger job with extra options" action which you can
> trigger directly from treeherder, that lets you set the environment,
> preferences, and a few other things:
>
> https://wlach.github.io/blog/2017/04/easier-reproduction-of-intermittent-test-failures-in-automation/
>
> That requires having an existing job to use as a template though.

Actions, too, are defined in-tree, and it's easy to define your own.
So if you have a common need to re-run a task with certain env vars
set, or extra command-line options, or whatever -- you can do that!  A
"retrigger with verbose logging" action would be trivial to develop,
for example.

Maybe I'm sounding like a broken record, but the I think this
particular sample deserves repeating (and maybe a bass drop for
emphasis).

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


Re: Stylesheet wait timeout?

2017-09-03 Thread Dustin Mitchell
Oops, the profile is from a *different* random github page from my
history, sorry for any confusion.

2017-09-03 12:40 GMT-04:00 Dustin Mitchell :
> I just reproduced it with a random page from my history:
> https://github.com/taskcluster/taskcluster-cli/issues/49.  Any github
> page will do, and it seems to have to do with caching.  if I delete
> today's history, I can reproduce.  And with a repro recipe, I can
> capture a profile -- https://perfht.ml/2wxZIpP
>
> Dustin
>
> 2017-09-02 16:58 GMT-04:00 Panos Astithas :
>> On Fri, Sep 1, 2017 at 7:37 PM, Boris Zbarsky  wrote:
>>
>>> I reported this issue to them (copy/paste of my report below) through the
>>> form at https://ghostery.zendesk.com/hc/en-us/requests/new but if someone
>>> has better contact info that might be nice.
>>>
>>
>> I have forwarded your message to my contacts at Cliqz (new owners of
>> Ghostery) and pointed them to this thread as well.
>>
>> Panos
>> ___
>> 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: Stylesheet wait timeout?

2017-09-03 Thread Dustin Mitchell
I just reproduced it with a random page from my history:
https://github.com/taskcluster/taskcluster-cli/issues/49.  Any github
page will do, and it seems to have to do with caching.  if I delete
today's history, I can reproduce.  And with a repro recipe, I can
capture a profile -- https://perfht.ml/2wxZIpP

Dustin

2017-09-02 16:58 GMT-04:00 Panos Astithas :
> On Fri, Sep 1, 2017 at 7:37 PM, Boris Zbarsky  wrote:
>
>> I reported this issue to them (copy/paste of my report below) through the
>> form at https://ghostery.zendesk.com/hc/en-us/requests/new but if someone
>> has better contact info that might be nice.
>>
>
> I have forwarded your message to my contacts at Cliqz (new owners of
> Ghostery) and pointed them to this thread as well.
>
> Panos
> ___
> 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: ./mach try fuzzy: A Try Syntax Alternative

2017-09-03 Thread Dustin Mitchell
That general mechanism is open-ended, though -- fuzzy is just one
interface to it.  The possibilities for shortcuts, purpose-specific
commands, and automation are enormous.

https://firefox-source-docs.mozilla.org/taskcluster/taskcluster/try.html

Dustin

2017-09-02 23:04 GMT-04:00 Andrew Halberstadt :
> On Sat, Sep 2, 2017 at 1:00 PM Randell Jesup  wrote:
>
>> >+to...@lists.mozilla.org
>> >
>> >There have been a bunch of new features added here I'd like to highlight:
>>
>> >   - --env: You can now set environment variables in your tasks directly
>> >   from the command line, e.g:
>> >  - ./mach try fuzzy --env XPCOM_DEBUG_BREAK=stack --env
>> >  MOZ_LOG="example_logger:3"|
>>
>> This is *awesome*; I've been wanting this for YEARS.  Does this work
>> without 'fuzzy'?
>>
>
> Yes and no :).
>
> There has been a --setenv option to try syntax for a fair while now, but
> I don't think it works with all tasks (likely just test tasks like
> mochitest,
> reftest, xpcshell, etc). I haven't tried this myself though, I'm not even
> sure
> if it's still working or not.
>
> The |mach try fuzzy| implementation is built on top of a much more general
> purpose mechanism that isn't (and won't be) available to try syntax. The
> main
> benefit of the |mach try fuzzy| implementation is that it will set the env
> in
> every task that gets scheduled no matter what kind/type.
>
>
>>   - --save/--preset: Works the same as try syntax, using the --query
>> >   argument. E.g:
>> >  - ./mach try fuzzy --save reftest -q "!cov !pgo 'reftest !jsreftest"
>> >  - ./mach try --preset reftest
>>
>> Also really great.
>>
>> --
>> Randell Jesup, Mozilla Corp
>> remove "news" for personal email
>> ___
>> 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: Stylesheet wait timeout?

2017-09-02 Thread Dustin Mitchell
I haven't distinguished between those two options -- I was making the
point that Ghostery isn't (exclusively) to blame.  Yes, it's that test
pilot.

The flashes (just saw another a moment ago) are on github.com.

Dustin

2017-09-01 17:01 GMT-04:00 Boris Zbarsky :
> On 9/1/17 10:15 AM, Dustin Mitchell wrote:
>>
>> I can narrow that bisection down to two sets: [test-pilot] and [].
>
>
> So test-pilot is causing the flash of unstyled content in your case?  I
> assume this is the addon at https://testpilot.firefox.com/ ?
>
> What pages are you seeing the flash of unstyled content on?
>
>
> -Boris
> ___
> 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: Stylesheet wait timeout?

2017-09-01 Thread Dustin Mitchell
I can narrow that bisection down to two sets: [test-pilot] and [].

Dustin

2017-09-01 9:54 GMT-04:00 Boris Zbarsky :
> On 9/1/17 7:02 AM, Gervase Markham wrote:
>>
>> Restarting with no extensions causes my browser to feel a whole lot
>> faster (I'd love to know why that is, but that's a separate issue!)
>
>
> Worth trying to bisect on the extensions to figure this out...
>
>> but I can't reproduce the FOUC in a few minutes of trying. :-|
>
>
> Again, worth trying to bisect on the extensions.  The
> not-reliably-reproducible aspect makes this a bit annoying.  :(
>
> -Boris
>
> ___
> 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: Stylesheet wait timeout?

2017-08-31 Thread Dustin Mitchell
I've seen it a few times now since this thread began.  I had Ghostery
installed but removed it a few days ago.  I only have whimsy
(disabled) and test pilot installed.

Dustin


2017-08-31 15:00 GMT-04:00 Michael Froman :
>
>> On Aug 31, 2017, at 1:08 PM, Boris Zbarsky  wrote:
>>
>> The symptoms you observe sound like (A) is happening, possible from an 
>> extension or our browser UI...  If you have a link to a specific url that 
>> reproduces for you, especially in a clean profile, that would be pretty 
>> useful.  This is usually pretty simple to debug when (A) happens: set a 
>> breakpoint on when we start layout and see what the JS stack is. The hard 
>> part is catching it happening.
> I’ve seen this behavior too on OSX.  I did a restart with all add-ons 
> disabled and could not reproduce.  Restarted with all add-ons on, and can 
> reproduce.  I narrowed it down to Ghostery.  If I disable Ghostery, it no 
> long appears to happen for me.  YMMV.
>
> -Michael.
>
> ___
> 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: Stylesheet wait timeout?

2017-08-31 Thread Dustin Mitchell
I've been seeing this, too, often on github pages.  I do not have
stylo enabled per about:support ("false (disabled by default)").

Dustin

2017-08-31 13:45 GMT-04:00 Chris Peterson :
> Gerv, do you have Stylo enabled? Even if you did not flip the pref
> (layout.css.servo.enabled), you might be in the Stylo experiment for Nightly
> users. Check about:support for "Stylo".
>
>
>
>
> On 2017-08-31 10:24 AM, Gervase Markham wrote:
>>
>> On 18/08/17 12:11, Gervase Markham wrote:
>> 
>>
>> Whereas what I meant to say was:
>>
>> Have we changed the timeout recently regarding how long Firefox waits
>> for a stylesheet before rendering the page? In the past few weeks I've
>> seen many more instances of a page loading unstyled, then re-laying out
>> a second later with style. It happens for me quite a bit on xkcd.com,
>> but there are other pages too.
>>
>> I think we may have set the timeout a bit low, because the result is ugly.
>>
>> I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.
>>
>> Gerv
>>
>
> ___
> 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: [tools-tc] Switching to TaskCluster Windows builds on Wednesday July 26th

2017-07-26 Thread Dustin Mitchell
This was a huge project full of detailed requirements and challenges,
and an important step in the taskcluster migration.  Congratulations
to everyone who worked so hard to make it happen!

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


Re: Switching to TaskCluster Windows builds on Wednesday July 26th

2017-07-21 Thread Dustin Mitchell
Nice work -- what a milestone!

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


Re: PSA: Requesting specific talos jobs in try syntax is broken on TC

2017-05-13 Thread Dustin Mitchell
Just to follow up, we've determined that the `-t all` issue was
bustage from something that landed yesterday.  It's fixed now.

Dustin

2017-05-13 15:04 GMT-04:00 Matthew N. :
> On 5/13/17 11:31 AM, Dustin Mitchell wrote:
>>
>> Specifically, -t for e10s talos doesn't work.  Non-e10s talos works
>> fine (but then, e10s talos are the interesting perf numbers..)
>
>
> That doesn't match my experience unless simply including an e10s talos job
> in the syntax also breaks the non-e10s ones.
>
>>> From the look of it, this has been broken since mid-March, but was
>>
>> only recently reported.  Note that issues like this are now fixable by
>> anyone who can write a patch, since they are defined in the source.
>> Sure, there's a bit of domain knowledge required, but it's just
>> (nicely commented, documented) code!
>
>
> The problem I'm seeing only started in the last week or so.
>
>> Dustin
>>
>> 2017-05-13 14:15 GMT-04:00 Matthew N. :
>>>
>>> See https://bugzilla.mozilla.org/show_bug.cgi?id=1363409 for details. It
>>> will still work on Win7 which uses buildbot, but won't on OS X or Linux
>>> which use Taskcluster (TC).
>>>
>>> The workaround is to request all talos jobs with `-t all`.
>
>
> Btw. I just tried this workaround and it also didn't give me any TC jobs but
> some other jobs did get them so it seems like there is another problem which
> is being discussed in #taskcluster.
>
>>> I'm just passing along the info to save others time
>>>
>>> Thanks,
>>> Matthew N. (:MattN)
>>>
>>> P.S. --rebuild-talos was also broken for a while but should now work
>>> again
>>> (bug 1317189)
>>> ___
>>> 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: PSA: Requesting specific talos jobs in try syntax is broken on TC

2017-05-13 Thread Dustin Mitchell
Specifically, -t for e10s talos doesn't work.  Non-e10s talos works
fine (but then, e10s talos are the interesting perf numbers..)

>From the look of it, this has been broken since mid-March, but was
only recently reported.  Note that issues like this are now fixable by
anyone who can write a patch, since they are defined in the source.
Sure, there's a bit of domain knowledge required, but it's just
(nicely commented, documented) code!

Dustin

2017-05-13 14:15 GMT-04:00 Matthew N. :
> See https://bugzilla.mozilla.org/show_bug.cgi?id=1363409 for details. It
> will still work on Win7 which uses buildbot, but won't on OS X or Linux
> which use Taskcluster (TC).
>
> The workaround is to request all talos jobs with `-t all`.
>
> I'm just passing along the info to save others time
>
> Thanks,
> Matthew N. (:MattN)
>
> P.S. --rebuild-talos was also broken for a while but should now work again
> (bug 1317189)
> ___
> 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: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Dustin Mitchell
Yep, this caused problems in automation (we ended up setting
I_PREFER_A_SUBOPTIMAL_MERCURIAL_EXPERIENCE_THANK_YOu or whatever the
env var was).  I agree that a quick warn-and-continue would be fine.

Dustin

2017-05-12 15:23 GMT-04:00 Eric Rahm :
> Didn't it somehow cause builds to fail? A gentle reminder is probably fine.
> TBH I'd be fine if it auto-updated but maybe I'm in the minority.
>
> On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:
>
>> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
>> > Would it be possible to add a check like:
>> > "You haven't updated your local configuration since XX days, please
>> > consider running
>> > mach bootstrap ?"
>>
>> We've had mach produce nag messages like that in the past and they have
>> been universally disliked, FWIW.
>>
>> -Ted
>> ___
>> 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


Build taskgraph generation landed

2016-09-13 Thread Dustin Mitchell
I think many of the concerned people were flagged for r? on bug
1286075, but for everyone else, it's landed in inbound today.

If you haven't mucked around with the configuration of which
TaskCluster tasks run for pushes, and how they run, then you can tune
out now.

If you have a project that I've rudely said "please wait until I land
this", then now is your chance!

The changes were pretty wide-spread, but the upshot is this:
taskcluster/ci/legacy is gone, as as all of the yaml files with their
weird inheritance hierarchies.  In their place is a better
implementation that should be more semantic and easier to modify or
extend.  This is well documented under http://gecko.readthedocs.io/
(or will be once it lands in central).

Please send any questions my way, as always!

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


Bug 1286075: major changes to in-tree task graph generation for non-test tasks

2016-09-07 Thread Dustin Mitchell
If you have worked on adding or modifying the gecko tasks that run in
taskcluster, heads up!

I've just pushed a patchset to bug 1286075 which will dramatically
change how tasks are configured.  Change for the better, of course!

Please see the bug for the details, but the general idea is that tasks
are now defined in a more semantic form ("to perform the frob task,
invoke mozharness with these frob-related options, while indexing the
task and displaying it in treeherder as fr(OB)") and that is then
interpreted using some simple, easiliy-modified logic to produce the
~870 tasks that run for each push.

In the process, the "legacy" kind, taskcluster/ci/legacy, has been deleted.

I have bitrotted a few patches I know of, and probably more I don't
know of.  For that, I am deeply sorry, but also hopeful that you will
like the new way better.  I've taken pains not to change the test
kinds much, so test-only changes should not be bitrotten.

Please head on over to the bug to have a look, and either comment
there or get in touch with me with any questions or concerns.

I plan to land this as soon as there are adequate r+'s -- like any
in-tree change, it can be backed out if it causes severe issues.  If
you'd like to know when it lands, please cc yourself to the bug.

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


TaskCluster issues closing tree this morning

2016-08-23 Thread Dustin Mitchell
Admin Assigned: jhford

Impact to service: Some TaskCluster worker types had backlogs of 30-60
minutes, including taskcluster-images jobs which must run before
builds can begin.  Trees are closed, preventing further check-ins.

Start Date/Time: 2016-08-23 07:12:00 PDT

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

Current Status: the underlying issue has been fixed, and backlogs are
falling.  Once they are within normal boundaries, trees will be
re-opened.

If you have questions about this issue, please email visit
#taskcluster in IRC. We appreciate your patience.

Thank you,
TaskCluster Team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

2016-05-20 Thread Dustin Mitchell
> BTW, starting yesterday, there was a "TaskClusterRobot" comment on my m-i
> push on GitHub with message "TaskCluster: @upsuper does not have permission
> to trigger tasks." [1][2]

This was due to an unfortunate interaction of the mirroring of gecko
to github, and the taskcluster-github component, which tried to run
it.  We've since fixed tc-github to ignore github pushes without any
github-specific configuration, so this is no longer an issue.

Please do file bugs for any remaining issues -- comments are easily
missed or forgotten on a mailing list.

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