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 9:
Hello team,
Thanks for using the ability of adding jobs to your pushes from
Treeherder [1].
I want to point out that some of you are having a great experience and
others not seeing anything happen or not all jobs being available.
There are some bugs in the code and efforts will be made in January
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
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,
Ar
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]
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=tc%20linu
w structure proposal.
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 ho
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
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 a
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
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&bug=1246152&attachment=8717111
I
al cause (the bug that 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.
> wrote:
>
>> Hello,
>> In order to help us have less timeouts when running mochit
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 wh
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 that was pointed out. I
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 yo
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 without any try syntax. If you do
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 ener
Do we know what happen with the data points of the end of the graph?
https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=%5Bmozilla-inbound,04b9f1fd5577b40a555696555084e68a4ed2c28f,1%5D&series=%5Bmozilla-inbound,65e0ddb3dc085864cbee77ab034dead6323a1ce6,1%5D&series=%5Bmozilla
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
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_ platform
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
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.
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
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. Hopefully
they could get fix be
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
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, I've been looking at re
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 inconvenie
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 Te
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 kn
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
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 a
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
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
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 p
he bug I'm 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.
Organi
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.
Unfort
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
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
_
On 2013-03-19 9:09 PM, L. David Baron wrote:
On Tuesday 2013-03-19 14:34 -0400, Armen Zambrano G. wrote:
Subject: Running Windows 8 tests visibly on mozilla-central, mozilla-inbound
and try
Besides three test suites (reftests, debug m-2 and debug m-o) all
other jobs are running constantly
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 th
ot seeing 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
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
(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 requested.
On 2013-04-25 1:40 PM, Andreas Gal wrote:>
> How many 10.7 machines do we operate in that pool?
>
> Andreas
84 of them are 10.6
86 of them are 10.7
Unfortunately, we have a lot of them down (maybe a dozen) trying to fix
them (broken hard drives, bad memory, NIC). They don't have warranty.
On 2
On 2013-04-26 9:10 AM, jmaher wrote:
On Thursday, April 25, 2013 4:12:16 PM UTC-4, Ed Morley wrote:
On 25 April 2013 20:14:10, Justin Lebar wrote:
Is this what you're saying?
* 10.6 opt tests - per-checkin (no change)
* 10.6 debug tests- reduced
* 10.7 opt tests -
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 to
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 to
-purpose the first batch of machines.
best regards,
Armen
On Fri, Apr 26, 2013 at 12:10 PM, Armen Zambrano G. 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 can re-visit later
machines".
Just 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. wrote:
On 2013-04-26 12:14 PM, Justin Lebar
Apr 26, 2013 at 1:03 PM, Armen Zambrano G. 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 run
Hi all,
We have started running Windows 7 test jobs in our new iX hardware on
the Cedar tree. These machines will replace our current Rev3 minis.
The reason I'm reaching you out is because I have found some
intermittent failures on those machines. I need some help investigating
them. I'm afra
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
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 not as
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
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-pla
://bugzilla.mozilla.org/show_bug.cgi?id=874922
best regards,
Armen
PS = We will keep on running it for m-b, m-r, esr17 and b2g release
branches. We will ride the trains.
On 2013-05-17 1:07 PM, Armen Zambrano G. wrote:
Hi all,
As of today, we run in parallel Windows 7 and Windows XP on iX
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
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
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
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 comp
(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 have
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 a
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 wi
illa-central/rev/3d1c2ca7efe8
On 2013-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
make sure that it all goes as expected.
cheers,
Jason & Armen
On 2013-07-22 2:44 PM, Armen Zambrano G. wrote:
Last week we enabled mozharness for talos on the try server and we have
resolved all found issues since then. The issues were related to proper
integration with tbpl and talos'
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
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:
This
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:0
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
Yes, we have.
+vlad
On 2013-10-09 7:35 PM, Kyle Huey wrote:
> Did we start caring about Win64 again recently?
>
> +bsmedberg
>
> - Kyle
>
>
> On Wed, Oct 9, 2013 at 7:33 PM, Jet Villegas wrote:
>
>> Excellent.
>>
>> Now to find willing volunteer(s.) Windows 64 represents a key platform for
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.
>
10.9 once we have the infrastructure up and running.
cheers,
Armen
[1] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard#Release_history
[2] https://en.wikipedia.org/wiki/Mac_OS_X_Lion#Release_history
On 2013-04-25 1:30 PM, Armen Zambrano G. wrote:
> (please follow up thro
On 11/22/2013, 12:29 PM, Ted Mielczarek wrote:
>
> I think this plan is generally sound. Users are moving en-masse to 10.9
> with the free update, so we should focus our resources there, and keep
> 10.6 around to support those users that can't update for hardware
> reasons. I just have one point o
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
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
https://li
, 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
>
_
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]) w
(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
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 b
any 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
+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 by next week.
On 13-12-12 12:12 PM, Ryan VanderMeulen wrote:
> On 12/12/2013 11:58 AM, arme...@mozilla.com wrote:
>
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 t
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
men
On 14-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 m
men
On 14-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 m
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
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
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
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 wil
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 fo
=818968#c106
regards,
Armen
On 2014-04-10, 6:36 PM, Armen Zambrano G. wrote:
> 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
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
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 is
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 allow
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 U
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 Jos
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:
>
>
> https://wiki.mozilla.
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
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'r
tl;dr; Next week, I would like to make all jobs on all trees stop using
the "production" branch of mozharness. Instead I want them to be pinned
to a specific version of mozharness.
Hello all,
Some of you may be aware that Mozharness runs a lot of jobs on
treeherder. You might also know that a
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 to
1 - 100 of 110 matches
Mail list logo
