Re: Fwd: Scheduling requests misbehaving in the last two days

It seems I forgot to hit send on Friday. You can request again "add new jobs" and "backfill" requests. Again, my apologies for this. regards, Armen On 2016-11-01 08:55 PM, Armen Zambrano G. wrote: Spreading the original information beyond the original mailing list. Unf

Fwd: Scheduling requests misbehaving in the last two days

using https://bugzilla.mozilla.org/show_bug.cgi?id=1314396 My apologies for this inconvenience. regards, Armen Forwarded Message Subject: Scheduling requests misbehaving in the last two days Date: Tue, 1 Nov 2016 14:21:12 -0400 From: Armen Zambrano G. <arme...@mozilla.

Usability improvements for Firefox automation initiative - Status update #8

NEW: * Debugging on remote workers is not a main priority for this quarter since it got completed * We've added investigating hyper chunking On this update we will look at the progress made in the last two weeks. This quarter’s main focus is on improving end to end times on Try (Thunder Try

Usability improvements for Firefox automation initiative - Status update #7

On this update we will look at the progress made in the last two weeks. A reminder that this quarter’s main focus is on: * Debugging tests on interactive workers (only Linux on TaskCluster) * Improve end to end times on Try (Thunder Try project) For all bugs and priorities you can check out the

Usability improvements for Firefox automation initiative - Status update #5

On this update we will look at the progress made in the last two weeks. A reminder that this quarter’s main focus is on: * Debugging tests on interactive workers (only Linux on TaskCluster) * Improve end to end times on Try (Thunder Try project) For all bugs and priorities you can check out the

Re: Report your development frustrations via `mach rage`

I agree with the last suggestion. Words and context matter. On 2016-08-08 04:25 PM, Jim Blandy wrote: LOL, but honestly, one of the ways I get myself to treat people better is to avoid the whole rage / tableflip / flame vocabulary when thinking about what I want to do. Could we publicize this

Usability improvements for Firefox automation initiative - Status update #2

On this update, we will look at the progress made since our initial update. A reminder that this quarter’s main focus is on: * Debugging tests on interactive workers (only Linux on TaskCluster) * Improve end to end times on Try (Thunder Try project) For all bugs and priorities you can check out

Re: Adding new jobs to pushes is not currently working

The Pulse infra issue has been resolved and we're now back to business. On 2016-07-18 10:38 AM, Armen Zambrano G. wrote: Hello, Treeherder sends a Pulse messages to add new jobs to your pushes. Those messages are currently not arriving, thus, the system won't work. If you want to know when

Usability improvements for Firefox automation initiative - Status update #1

The developer survey conducted by Engineering Productivity last fall indicated that debugging test failures that are reported by automation is a significant frustration for many developers. In fact, it was the biggest deficit identified by the survey. As a result, the Engineering Productivity

Adding new jobs to pushes is not currently working

Hello, Treeherder sends a Pulse messages to add new jobs to your pushes. Those messages are currently not arriving, thus, the system won't work. If you want to know when it gets fixed you can follow this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1287404 Our apologies for any

Re: Making try faster for debugging intermittents

On 2016-07-01 06:10 AM, Mike Hommey wrote: On Fri, Jul 01, 2016 at 03:07:43PM +1000, Xidorn Quan wrote: On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: William Lachance writes: As part of a larger effort to improve the experience around debugging intermittents,

Adding jobs to Treeherder will now show a 'Sch' job with the outcome of the request

Hello all, Until now, adding jobs to Treeherder was completely opaque. As of today you will see a "Sch" job start running soon after you make your request. You will have access to logs and a link to file a bugs. Filing bugs will help when my alerting system does not catch issues. I have all

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

On 2016-05-19 08:29 PM, Mike Hommey wrote: On Thu, May 19, 2016 at 07:20:30PM -0500, J. Ryan Stinnett wrote: On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan wrote: 2. I cannot retrigger any TC task. This is pretty annoying when I was debugging intermittent issues.

Re: Two talos jobs for PGO builds on fx-team and m-i

My apologies. I looked at the "default" value rather than the project specific cadence. https://dxr.mozilla.org/build-central/source/buildbot-configs/mozilla/project_branches.py#20 On 2016-05-12 11:12 AM, Ryan VanderMeulen wrote: On 5/12/2016 10:51 AM, Armen Zambrano G. wrote: IIU

Re: Two talos jobs for PGO builds on fx-team and m-i

will this have on machine capacity? The Windows and Mac testers are already highly overwhelmed. Try jobs are often delayed by several hours, which I think is a major concern. (I can't remember if we have a separate pool for Talos testers [on Try].) On May 12, 2016, at 05:01, Armen Zambrano G. <a

Two talos jobs for PGO builds on fx-team and m-i

Hello team, We're now scheduling two talos jobs for every PGO build on fx-team [1] and m-i. This is to help reduce the time it takes to find PGO specific regressions for these two branches. If you see any issues falling out of this please file it under Testing::General and CC me. This is

Re: PSA: Cancel your old Try pushes

On 2016-04-26 05:54 PM, Mike Hommey wrote: On Tue, Apr 26, 2016 at 03:49:11PM +0200, Gabor Krizsanits wrote: As someone who was high on the list of try server usage for two weeks My problem was a test I tried to fix for both e10s and non-e10s, and it timed out _sometimes_ on _some_

Adding new jobs to treeherder does not work for Linux64 debug jobs

Hello team, Recently we hid the Linux64 debug jobs that run on Buildbot since we have the TaskCluster version covering that. Unfortunately, you won't be able to add Linux64 debug jobs *even* if Treeherder shows them to you (they will be scheduled but hidden). We will have someone working on

Re: Build System Project - Update from the last 2 weeks

Do we know what happen with the data points of the end of the graph?

Re: Moving XP to ESR?

Would it make more sense to have a relbranch instead of using ESR? IIRC ESRs are stable for a period but when we uplift we uplift everything new. For this XP relbranch we would only take security patches. It would serve the purpose of keeping our users secure where they're but saving some

Re: Try syntax is no longer required when pushing to try

On 16-03-03 08:35 PM, Xidorn Quan wrote: > On Fri, Mar 4, 2016 at 1:25 AM, Andrew Halberstadt > wrote: > >> With treeherder's "Add New Jobs" [1] UI, using try syntax is no longer >> the only way to schedule stuff on try. As of now, it's possible to push >> to try

Re: Try syntax is no longer required when pushing to try

On 16-03-04 01:22 AM, Mike Hommey wrote: > On Thu, Mar 03, 2016 at 12:25:53PM -0500, Andrew Halberstadt wrote: >> With treeherder's "Add New Jobs" [1] UI, using try syntax is no longer >> the only way to schedule stuff on try. As of now, it's possible to push >> to try without any try syntax. If

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On 16-02-10 04:58 AM, Marco Bonardo wrote: > On Wed, Feb 10, 2016 at 10:30 AM, James Graham > wrote: > >> FWIW I think it's closer to the truth to say that these tests are not set >> up to be performance regression tests >> > > Right, but this was just one of the aspects

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

e it sound like this change affected all mochitests.) > > Thanks, > ~Daniel I'm interested in browser-chrome. Is there a different variable for those tests? > > On 02/08/2016 02:51 PM, Armen Zambrano G. wrote: >> Hello, >> In order to help us have less timeouts when running

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

at takes 80s to > run) to figure if something can be done to make it finish sooner? > > -m > > > On Mon, Feb 8, 2016 at 11:51 PM, Armen Zambrano G. <arme...@mozilla.com> > wrote: > >> Hello, >> In order to help us have less timeouts when running

To bump mochitest's timeout from 45 seconds to 90 seconds

Hello, In order to help us have less timeouts when running mochitests under docker, we've decided to double mochitests' gTimeoutSeconds and reduce large multipliers in half. Here's the patch if you're curious: https://bugzilla.mozilla.org/page.cgi?id=splinter.html=1246152=8717111 If you have any

Use --interactive in try syntax to SSH into docker image

Hello, This was demonstrated at Mozlando by gardnt and jonasfj. To use it: * add --interactive to your try syntax * wait for the task to start running * click on "Inspect task" hyperlink * bottom left of page when you click a job on Treeherder * click on 'private/docker-worker/shell.html' under

Re: Use --interactive in try syntax to SSH into docker image

the tests! Known bug: If you use --interactive your push will show up as green (bug 1232385) On 16-02-02 02:27 PM, Armen Zambrano G. wrote: > Hello, > This was demonstrated at Mozlando by gardnt and jonasfj. > > To use it: > * add --interactive to your try syntax > * wait f

Shutting try extender off (please add jobs through Treeherder)

I'm going to be shutting off try-extender [1] on February 5th since you can accomplish the same via Treeherder ('add new jobs' button). I've fixed all known bugs and I have bandwidth to help in case new issues arise. In the future, more features will come to give you proper feedback when things

Testing documentation (was Re: Where to put docker documentation?)

. regards, Armen On 16-01-22 02:23 PM, Mike Hoye wrote: > On 2016-01-22 12:07 PM, Armen Zambrano G. wrote: >> We're now running side by side Linux x64 debug test jobs inside of >> docker on TaskCluster [1] >> >> Where could I add instructions on how to run jobs runnin

Where to put docker documentation?

We're now running side by side Linux x64 debug test jobs inside of docker on TaskCluster [1] Where could I add instructions on how to run jobs running inside of docker? (mdn? the tree? else?) regards, Armen [1]

Re: Just Autoland It

On 16-01-22 08:16 AM, Jared Wein wrote: > If a patch only touches JS and CSS, could tryserver use the archive build > implementation to generate faster try builds? > We could do things like that (We can tell test jobs to grab the installer and test packages from different locations). regards,

Adding new jobs to pushes in better shape

I've spent the last two days fixing most issues affecting adding jobs on Treeherder. I believe it is now working properly. You don't need to try multiple times. Remember: * this does not work with TaskCluster jobs [1] * if you own the push, you can add jobs * if you use and @mozilla.com, you have

Re: FYI: e10s will be enabled in beta 44/45

LastPass bring the browser to a crawl making it almost impossible to use. If we have users using LastPass on the beta population using e10s we're going to have a lot of people upset. https://bugzilla.mozilla.org/show_bug.cgi?id=1008768 On 15-12-04 10:44 AM, Ehsan Akhgari wrote: > On 2015-12-04

If you run mozharness on your local machine (tooltool changes)

Hello all, At the end of last year we made some changes to make mozharness more easy to run outside of the Release Engineering VPN. Mozharness is the python harness that runs most jobs that show up on Treeherder. Tooltool has been re-written recently [1], you will now need a token on your machine

Re: (mozci) Triggering jobs on treeherder

Thank you all for reading through the post and the feedback. It seems that there is interest for this. On 15-04-24 06:06 PM, Mike Hommey wrote: On Fri, Apr 24, 2015 at 10:26:58PM +0100, Gijs Kruitbosch wrote: Are you going to build a web UI for this so I don't need to check out a repo and run

(mozci) Triggering jobs on treeherder

Hello all, We wrote last quarter a project called Mozilla CI tools (mozci) which allows triggering jobs on treeherder. [1] This is specially useful for back-filling jobs (specially when coalesced) and bisecting via job triggering. Specifically, I want to bring to your attention a use case

Re: Win64 builds tests coming soon!

As of today we also have: * Win64 opt talos * Win64 pgo builds, tests and talos Both of them running on Windows 8 64-bit test machines. On graphs.m.o you should recognize the platform as WINNT 6.2 x64. cheers, Armen On 14-10-21 04:00 PM, Chris AtLee wrote: Hi, Just a quick note that we're

Re: How to run browser rooting analysis of mozharness locally?

Filed to make it clearer next time: https://bugzilla.mozilla.org/show_bug.cgi?id=1067354 Thanks for trying it! On 14-09-15 12:11 AM, Ting-Yu Chou wrote: Hi, The patch of bug 1049290 failed linux64-br-haz_try_dep, I am trying to debug it locally. I read:

Re: Running mozharness locally and be able to reach private files

For now, this is only limited to test jobs. I should have made emphasis on it. My apologies about it. I was hoping to deal with different use cases as people tried them out. Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1067354 On 14-09-11 08:58 AM, Armen Zambrano G. wrote: Hello all

Running mozharness locally and be able to reach private files

Hello all, It is now less hard to run mozharness locally by appending --cfg developer_config.py to production commands. Appending the config will activate a developer mode which does the following: * Remove hard coded paths for binaries * Substitute internal URLs to point to externally reachable

Re: Running mozharness locally and be able to reach private files

On 14-09-11 09:03 AM, Joshua Cranmer  wrote: On 9/11/2014 7:58 AM, Armen Zambrano G. wrote: What would people want to see in the long term to make mozharness easier for you? A Dockerfile (or a container image) that produces a Ubuntu64 test slave. Hi Joshua, that would be ideal, however

MozHarness outside of loaners and releng network

Hello, There are some recent improvement to mozharness that helps running the jobs outside of tbpl and releng loaned machines: * Http authentication ** e.g. http authentication for pvtbuilds * Url substitutions ** Hit external reachable hosts instead of internal ones * Developer configs ** It

Trigger arbitrary jobs on your Try push (or other pushes)

Hello, A while ago, zeller, catlee and hwine worked on getting a new BuildAPI available [1]. This allows you to trigger an arbitrary job on the releng/tbpl system post a push. I've put together a script that helps hitting that API [2][3]. The API allows you to use a hand zipped tests.zip which

Re: OMTC on Windows

What kind of bugs could we expect seeing? Any place you would like us to put focus on testing? Thanks for all the hard work to get this in. cheers, Armen On 2014-05-18, 3:16 AM, Bas Schouten wrote: Hey all, After quite a lot of waiting we've switched on OMTC on Windows by default today

Disabling b2g reftests on the minis on trunk

Hello, Due to bug 907770 we're going to disable b2g reftests on the trunk trees on the Mac Rev3 minis a week earlier. We will keep running b2g reftests on the EC2 instances. The b2g reftests on EC2 having reliably green for several weeks already. Next week we will disable the jobs on the minis

Re: Linux testing on single-core VMs nowadays

We do talos testing on in-house machinery (iX machines with 4-core). Not sure if that would trigger some of the issues you are hoping to be caught. In the future, we should be able to have some jobs run on different EC2 instance types. See https://bugzilla.mozilla.org/show_bug.cgi?id=985650 It

Re: Spring cleaning: Reducing Number Footprint of HG Repos

On 14-03-26 07:53 PM, Taras Glek wrote: *User Repos* TLDR: I would like to make user repos read-only by April 30th. We should archive them by May 31st. Time spent operating user repositories could be spent reducing our end-to-end continuous integration cycles. These do not seem like

Re: Spring cleaning: Reducing Number Footprint of HG Repos

On 14-03-26 08:27 PM, Bobby Holley wrote: I don't understand what the overhead is. We don't run CI on user repos. It's effectively just ssh:// + disk space, right? That seems totally negligible. FTR from an operations standpoint, it is never just. Never. If it was *just* we wouldn't even be

Re: Test harness options now defined in-tree -- please pull m-c before pushing to try!

On 14-03-26 09:11 AM, Andrew Halberstadt wrote: On 26/03/14 09:06 AM, Andrew Halberstadt wrote: On 26/03/14 12:19 AM, Gregory Szorc wrote: Andrew: I'm curious if you or anyone else has given any consideration into making it dead simple to change the config so only a subset of tests will be

Re: Running b2g reftests on mozilla-inbound on EC2 instances

-03-14 11:14 AM, Armen Zambrano G. wrote: Hello, We're trying to move the b2g reftests from the old Mac minis to run on the EC2 instances. We're going to run the jobs side-by-side on mozilla-inbound for few days to see how it behaves with more load [1]. If you see the jobs misbehaving

Re: Running b2g reftests on mozilla-inbound on EC2 instances

-03-14 11:14 AM, Armen Zambrano G. wrote: Hello, We're trying to move the b2g reftests from the old Mac minis to run on the EC2 instances. We're going to run the jobs side-by-side on mozilla-inbound for few days to see how it behaves with more load [1]. If you see the jobs misbehaving

Running b2g reftests on mozilla-inbound on EC2 instances

Hello, We're trying to move the b2g reftests from the old Mac minis to run on the EC2 instances. We're going to run the jobs side-by-side on mozilla-inbound for few days to see how it behaves with more load [1]. If you see the jobs misbehaving please hide them and let us know in bug 818968. The

Re: Disabling Mac + Linux32-bit builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd

I've heard no objections. I will proceed with this plan. On 13-12-12 01:35 PM, Armen Zambrano G. wrote: +dev.b2g tl;dr - we want to disable Mac + Linux32-bit build/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd Hi Ryan, I would be fine of taking care of it if I hear no objections

Disable Windows builds and nightly builds on b2g18 and b2g18-v1.0.0-hd

concerns about it: https://bugzilla.mozilla.org/show_bug.cgi?id=948135 cheers, Armen On 13-12-09 01:52 PM, Armen Zambrano G. wrote: Changing the subject to make it more clear. I will be raising this on the Monday weekly call as well as the Engineering meeting. On 13-12-07 03:31 PM, Armen Zambrano

Disabling Windows 7 testing and nightly builds on b2g18 and b2g18-v1.0.0-hd

Changing the subject to make it more clear. I will be raising this on the Monday weekly call as well as the Engineering meeting. On 13-12-07 03:31 PM, Armen Zambrano G. wrote: (Please follow up on mozilla.dev.b2g) Adding dev.platform to reach a wider audience. I will bring this up

Re: Desktop unit tests and nightly builds on b2g18 and b2g18-v1.0.0-hd

(Please follow up on mozilla.dev.b2g) Adding dev.platform to reach a wider audience. I will bring this up at the Engineering meeting on Tuesday in case I don't hear anything back by Tuesday. cheers, Armen On 13-12-06 02:50 PM, Armen Zambrano G. wrote: Hi all, Given that we are only doing

Killing ESR17 builds tests on tbpl

Hello all, Next week, we will have our next merge date [1] on Dec. 9th, 2013. As part of that merge day we will be killing the ESR17 builds and tests [2][3] for tbpl.mozilla.org. This is part of our normal process where two merge days after the creation of the latest ESR release (e.g. ESR24 [3])

Disabling today the 10.7 test infrastructure across the board

This is part 1 of the thread Proposed changes to RelEng's OSX build and test infrastructure. I wanted to make it very clear so no one is surprised when it happens. cheers, Armen ___ dev-platform mailing list dev-platform@lists.mozilla.org

[completed] Re: Disabling today the 10.7 test infrastructure across the board

, 10:11 AM, Armen Zambrano G. wrote: This is part 1 of the thread Proposed changes to RelEng's OSX build and test infrastructure. I wanted to make it very clear so no one is surprised when it happens. cheers, Armen ___ dev-platform mailing list

Re: Proposed changes to RelEng's OSX build and test infrastructure

On 11/22/2013, 3:44 PM, Johnathan Nightingale wrote: On Nov 22, 2013, at 12:29 PM, Ted Mielczarek wrote: On 11/21/2013 4:56 PM, John O'Duinn wrote: 6) If a developer lands a patch that works on 10.9, but it fails somehow on 10.7 or 10.8, it is unlikely that we would back out the fix, and we

Re: how long are we continuing 32-bit OS X support?

Releng note: if we stop it, we could also get much better test capacity on tbpl as we could re-purpose our 10.6 test infrastructure. cheers, Armen On 2013-10-21 1:14 PM, Ehsan Akhgari wrote: Note that we also use this to support 32-bit plugins, so our target audience is not just 10.6 users.

Switching talos jobs to not grab files from http://build.mozilla.org/talos

Hi, After Sep. 30th we will not be grabbing files anymore from http://build.mozilla.org/talos but from http://talos-bundles.pvt.build.mozilla.org. As of today, all changes have landed and made live for all of our development trees (including esr and b2g18 trees). Any _talos_ jobs that are pushed

talos mozharness status

10:17 AM, Armen Zambrano G. wrote: Talos mozharness is now live on all FF25 trees. Remember that we will see some ts regressions. More info in: http://armenzg.blogspot.ca/2013/07/enabling-talos-mozharness-for-ff25.html This will ride the trains. cheers, Jason Armen On 2013-07-29 1:04 PM, Armen

[LIVE] Enabling mozharness for talos for FF25 projects

Talos mozharness is now live on all FF25 trees. Remember that we will see some ts regressions. More info in: http://armenzg.blogspot.ca/2013/07/enabling-talos-mozharness-for-ff25.html This will ride the trains. cheers, Jason Armen On 2013-07-29 1:04 PM, Armen Zambrano G. wrote

Re: [RE-SCHEDULED] Re: Enabling mozharness for talos for FF25 projects

This will be going live tomorrow Tuesday 30th. On 2013-07-23 4:38 PM, Armen Zambrano G. wrote: I need these new changesets to spread across the FF25 trees before going ahead with this: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e https://hg.mozilla.org/integration/mozilla

Enabling mozharness for talos for FF25 projects (was Re: Running talos through mozharness)

-07-16 8:51 AM, Armen Zambrano G. wrote: Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run

Running talos through mozharness

Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run talos inside of our infrastructure

New Windows 7 and XP try syntax

FYI Before: try: -b do -p win32 -u all[5.1,6.1] -t none Now: try: -b do -p win32 -u all[Windows XP,Windows 7] -t none This trigger jobs on the iX hardware rather than the Rev3 minis. FYI we disabled today jobs on Rev3 minis. The Try Syntax Chooser page has also been updated. cheers, Armen

Re: Hide Windows 7 and Windows XP jobs for Rev3 minis

I did not do this last night. I will be doing this now and take into account the request of mbrubeck. On 2013-05-22 11:38 AM, Matt Brubeck wrote: On 5/22/2013 10:22 AM, Armen Zambrano G. wrote: We would like to determine if we are ready to stop running jobs on the rev3 minis before stopping

Re: Disable this Thursday Windows 7 and Windows XP on Rev3 machines

This is live since this morning. Thank you all that helped make this happen. http://armenzg.blogspot.com/2013/05/kiss-old-testing-infra-revision-3-mac.html On 2013-05-28 1:08 PM, Armen Zambrano G. wrote: (posting to dev.platform and dev.tree-management) Hello all, We have been running unit

Pink pixel of death (reftest failures due to bad RAM)

Hi all, We have found that sometimes we fail our reftest tests due to a couple of pixels getting store in bad sectors on the RAM of our machines. We have also seen garbage collection crashes due to it. We have also recently discovered that memtest has done a better job at catching bad RAM

Disable this Thursday Windows 7 and Windows XP on Rev3 machines

(posting to dev.platform and dev.tree-management) Hello all, We have been running unit tests and talos jobs on the iX hardware for a while side by side with the Rev3 minis. We have disabled the Rev3 minis jobs for few days in on our main tbpl pages and we have not missed them AFAIK. We

Disabled Gaia UI tests on pandas - any reason for B2G *panda* builds?

Hi, Today, we disabled Gaia UI tests on the B2G pandas [1][2][3]. The reason is that they were broken and our testing plan is to test on Desktop builds rather than pandas [3]. At some point we used to run these jobs across all trees, then we hid them, then we only left them running on Cedar

Re: Running Windows 7 XP jobs on ix hardware

On 2013-05-17 1:07 PM, Armen Zambrano G. wrote: * Windows XP on iX is running *hidden* on m-i, try and cedar I didn't see any perma-oranges so I made them visible. I will be adding the remaining branches tomorrow. cheers, Armen ___ dev-platform

Running Windows 7 XP jobs on ix hardware

Hi all, As of today, we run in parallel Windows 7 and Windows XP on iX hardware as well as on minis. Current status: * Windows 7 on iX is running *visible* on FF23 based trees * Windows XP on iX is running *hidden* on m-i, try and cedar Sometime after Tuesday, I will: * Evaluate and propose a

Re: Windows 7 test jobs running on iX

These jobs are now running across the board up to mozilla-aurora. It seems that dromaeo css on pgo is misbehaving: https://bugzilla.mozilla.org/show_bug.cgi?id=870453 cheers, Armen On 2013-05-13 11:23 AM, Armen Zambrano G. wrote: The intermittent failures on consecutive changesets were

Re: Windows 7 test jobs running on iX

The intermittent failures on consecutive changesets were not as bad as I first thought. This week we should have the jobs be running across all branches. IT should have the machines ready between Tuesday to Wednesday. cheers, Armen On 2013-05-09 3:20 PM, Armen Zambrano G. wrote: Hi all, We

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

Would we be able to go back to where we disabled 10.7 altogether? Product (Asa in separate thread) and release drivers (Akeybl) were OK to the compromise of version specific test coverage being removed completely. Side note: adding Mac PGO would increase the build load (Besides this we have

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. Any objections on this plan? We can re-visit later on if we need more disabled. cheers, Armen On 2013-04-26 11:50 AM, Armen Zambrano G. wrote: Would we be able

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

-purpose the first batch of machines. best regards, Armen On Fri, Apr 26, 2013 at 12:10 PM, Armen Zambrano G. arme...@mozilla.com wrote: Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. Any objections on this plan? We

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

a little before on the thread you were asking go big or go home and asked to disable even 10.6 debug tests. I'm confused about the different messages. On Fri, Apr 26, 2013 at 1:03 PM, Armen Zambrano G. arme...@mozilla.com wrote: On 2013-04-26 12:14 PM, Justin Lebar wrote: Would we be able

Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load

PM, Armen Zambrano G. arme...@mozilla.com wrote: On 2013-04-26 12:14 PM, Justin Lebar wrote: Would we be able to go back to where we disabled 10.7 altogether? On m-i and try only, or everywhere? The initial proposal was for disabling everywhere. We could leave 10.7 opt jobs running

Improving Mac OS X 10.6 test wait times by reducing 10.7 load

(please follow up through mozilla.dev.planning) Hello all, I have recently been looking into our Mac OS X test wait times which have been bad for many months and progressively getting worst. Less than 80% of test jobs on OS X 10.6 and 10.7 are able to start within 15 minutes of being

Re: Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)

delays to be processed. best regards, Armen [1] https://bugzilla.mozilla.org/show_bug.cgi?id=814009 [2] trychooser has been updated and this is the syntax: try: -b o -p win64 -u none -t none On 2013-03-27 1:19 PM, Armen Zambrano G. wrote: Hi, We're currently suffering lack of capacity

Re: Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)

On 2013-03-27 1:29 PM, Benjamin Smedberg wrote: On 3/27/2013 1:19 PM, Armen Zambrano G. wrote: On another note, there could be a tree booked for win64 and move nightly win64 users there (orthogonal to updating users to 32-bit builds) since it would allow the community control which merges from

Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)

Hi, We're currently suffering lack of capacity on the win64 builders. I noticed that we still run win64 dependent builds for Thunderbird Firefox. I would like to disable those since they cost approximately 1/3 of our load (win32 opt/debug win64 opt). If anyone has a strong objection for

Running Windows 8 tests visibly on mozilla-central, mozilla-inbound and try

Hi, Besides three test suites (reftests, debug m-2 and debug m-o) all other jobs are running constantly green. If you want to read more about it visit http://armenzg.blogspot.ca/2013/03/running-windows-8-tests-visibly-on-tbpl.html best regards, Armen

Deployed _dumbwin32proc.py to all win7 and winxp machines

Hi, This morning I deployed a different version of _dumbwin32proc.py to all of our Win7 (talos-r3-w7-*) and WinXP machines (talos-r3-xp-*). This different version allows the machines to kill processes that currently could not be killed. For instance, when we asked a job to be interrupted. It

Windows 8 and our continuous integration system (tbpl)

Hi all, IT and RelEng are working on creating a new test infrastructure to make obsolete our current Rev3 machines. To better meet our needs, we want to make sure that we test Firefox 32-bit on the right set of platforms. Mozilla currently has continuous integration running (on tbpl.mozilla.org)

Re: Windows 8 and our continuous integration system (tbpl)

in direct threads said that this plan is good. On Tuesday, November 6, 2012 9:00:29 AM UTC-5, Armen Zambrano G. wrote: Hi all, IT and RelEng are working on creating a new test infrastructure to make obsolete our current Rev3 machines. To better meet our needs, we want to make sure that we

Re: New backout policy for Ts regressions on mozilla-inbound

Is there a place where this will be document? I would like to keep an eye on what gets added or point people at it. This is awesome! Looking forward to see how it goes. thanks Ehsan On 2012-10-18 2:05 PM, Ehsan Akhgari wrote: Hi everyone, As part of our efforts to get more value out of the

Re: ERROR: Logon failure: unknown user name or bad password. on mochitests

On 12-09-27 7:03 AM, Neil wrote: Clint Talbert wrote: On 9/26/2012 8:32 AM, Armen Zambrano G. wrote: On 12-09-26 6:45 AM, Neil wrote: Perhaps the file system permissions are incorrect and NT AUTHORITY\NETWORK SERVICE doesn't have permission to access C:\WINDOWS\system32\wbem\wmiprvse.exe

Re: ERROR: Logon failure: unknown user name or bad password. on mochitests

On 12-09-26 6:45 AM, Neil wrote: Armen Zambrano G. wrote: Hi all, Recently we've set up some new XP slaves that fail on mochitest jobs due to this error: ERROR: Logon failure: unknown user name or bad password. Unfortunately, I have not been able what is triggering that error (I can't find