FYI: Taskcluster Services Migration
*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
*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
@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
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
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
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)
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
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
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 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
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 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?
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?
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
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?
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?
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?
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?
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
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
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
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
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?
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
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
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
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!)
> 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