OSX builds extremely slow to start #7304

Closed
awnumar opened this Issue Feb 10, 2017 · 40 comments

Comments

Projects
None yet
@awnumar

awnumar commented Feb 10, 2017

Recently I added OSX to my project's testing cycle. Previous to the change, the entire test took about 30 seconds to start, run everything, and report back. Now it takes about half an hour before even starting the build. Upon clicking the build status and going to the log, I get a message of "Hang tight, the log cannot be shown until the build has started.", while the Linux build has already completed and passed a long time ago.

Any help?

@NoahAndrews

This comment has been minimized.

Show comment
Hide comment
@NoahAndrews

NoahAndrews Feb 11, 2017

Look at the status page. While the number of running Linux jobs fluctuates constantly as new VMs are created and destroyed, the number of running Mac jobs stays almost constant, which results in a big backlog. I'm sure this has to do with Mac builds having to be run on real Mac hardware. Unfortunately, this is just a thing we have to live with.

Look at the status page. While the number of running Linux jobs fluctuates constantly as new VMs are created and destroyed, the number of running Mac jobs stays almost constant, which results in a big backlog. I'm sure this has to do with Mac builds having to be run on real Mac hardware. Unfortunately, this is just a thing we have to live with.

@awnumar

This comment has been minimized.

Show comment
Hide comment
@awnumar

awnumar Feb 11, 2017

@NoahAndrews Ah right. I should hack checked that.

Closing this thread. Feel free to reopen if you feel this is a problem that needs to be addressed.

awnumar commented Feb 11, 2017

@NoahAndrews Ah right. I should hack checked that.

Closing this thread. Feel free to reopen if you feel this is a problem that needs to be addressed.

@awnumar awnumar closed this Feb 11, 2017

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Mar 8, 2017

I think since the slow start is a norm rather than an exception these days then perhaps travis-build should have two job queues, i.e. one queue dedicated for osx and the other one for the rest. For example, if we have 3 queued jobs for osx and 30 queued jobs for Linux; and when there is huge backlog for osx, then on the Linux side travis-build should still give us 5 concurrent build at a time to clear the 30 queued jobs. Currently it would just give us 2 (i.e. 5 - 3) concurrent build at a time. In a nutshell, our build on the Linux side is being penalized by the huge osx backlog, which is not fair at all.

weitjong commented Mar 8, 2017

I think since the slow start is a norm rather than an exception these days then perhaps travis-build should have two job queues, i.e. one queue dedicated for osx and the other one for the rest. For example, if we have 3 queued jobs for osx and 30 queued jobs for Linux; and when there is huge backlog for osx, then on the Linux side travis-build should still give us 5 concurrent build at a time to clear the 30 queued jobs. Currently it would just give us 2 (i.e. 5 - 3) concurrent build at a time. In a nutshell, our build on the Linux side is being penalized by the huge osx backlog, which is not fair at all.

@awnumar awnumar reopened this Mar 8, 2017

@AnthonyOliveri

This comment has been minimized.

Show comment
Hide comment
@AnthonyOliveri

AnthonyOliveri Mar 8, 2017

For me, this is a serious issue and has a huge impact on my productivity with my Xcode projects. This has been an issue for the past few months that I've been using Travis, and has been steadily getting worse. My builds are now taking 3 hours on average to get started.

Can someone from the Travis team explain any plans to ameliorate this situation? There is clearly a huge demand for Mac builds, with not nearly enough hardware to support it.

For me, this is a serious issue and has a huge impact on my productivity with my Xcode projects. This has been an issue for the past few months that I've been using Travis, and has been steadily getting worse. My builds are now taking 3 hours on average to get started.

Can someone from the Travis team explain any plans to ameliorate this situation? There is clearly a huge demand for Mac builds, with not nearly enough hardware to support it.

@awnumar

This comment has been minimized.

Show comment
Hide comment
@awnumar

awnumar Mar 8, 2017

Keeping in mind that this is a brilliant service provided for free, the OSX build speed really is getting to the point where it's past annoying and just counterproductive. I think everyone would appreciate a comment from the Travis team about whether this is likely to be fixed, when and how.

awnumar commented Mar 8, 2017

Keeping in mind that this is a brilliant service provided for free, the OSX build speed really is getting to the point where it's past annoying and just counterproductive. I think everyone would appreciate a comment from the Travis team about whether this is likely to be fixed, when and how.

@AnthonyOliveri

This comment has been minimized.

Show comment
Hide comment
@AnthonyOliveri

AnthonyOliveri Mar 8, 2017

I agree that we should be grateful that we get these builds for free, but I was told that even paid versions do nothing to speed up Mac builds. Can anyone confirm or deny that this is the case?

I agree that we should be grateful that we get these builds for free, but I was told that even paid versions do nothing to speed up Mac builds. Can anyone confirm or deny that this is the case?

@scottrhoyt

This comment has been minimized.

Show comment
Hide comment
@scottrhoyt

scottrhoyt Mar 13, 2017

I can confirm that on a paid plan it still takes my builds about 15 - 60 minutes to start during peak times (pretty much US business hours). They start quicker off-peak but that is only marginally helpful to us. It is a becoming a big productivity drain. This is particularly true when we have many PRs that get opened simultaneously. Travis's feature of building every PR (which I love) results in non-linear growth of your build queue as you begin merging them. We have begun to be conscious of how many PRs we leave open at once for this reason, which is another hit to organization and productivity.

I can confirm that on a paid plan it still takes my builds about 15 - 60 minutes to start during peak times (pretty much US business hours). They start quicker off-peak but that is only marginally helpful to us. It is a becoming a big productivity drain. This is particularly true when we have many PRs that get opened simultaneously. Travis's feature of building every PR (which I love) results in non-linear growth of your build queue as you begin merging them. We have begun to be conscious of how many PRs we leave open at once for this reason, which is another hit to organization and productivity.

@loint

This comment has been minimized.

Show comment
Hide comment
@loint

loint Mar 15, 2017

OSX very slow from start. After booting then it's in queue now. Any idea help to solve it for travis-ci.com because it's a paid service. Can not be slow by anyway !!! 👎

loint commented Mar 15, 2017

OSX very slow from start. After booting then it's in queue now. Any idea help to solve it for travis-ci.com because it's a paid service. Can not be slow by anyway !!! 👎

@loint

This comment has been minimized.

Show comment
Hide comment
@loint

loint Mar 15, 2017

@AnthonyOliveri Agree with you too.

loint commented Mar 15, 2017

@AnthonyOliveri Agree with you too.

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Mar 19, 2017

Member

Hi Everyone

I'm sorry for the issues you have experienced with jobs taking a long time to start.

From some of the comments in this thread, I think there might be a confusion between travis-ci.org and travis-ci.com. I wanted to try and clear up some of this confusion, or at least try to understand it better :)

The Mac queues for travis-ci.org and travis-ci.com are separate in terms of provisioned capacity, but use the same underlying infrastructure. We make sure we have enough provisioned capacity for our customers on travis-ci.com who are testing private Repositories on our Mac infrastructure. For travis-ci.org we provide a greater capacity, in terms of concurrent VMs, but have had to make some hard decisions on how and when to increase this capacity as the cost for helping the open source community is fairly high.

If you are a customer on travis-ci.com and you find your jobs are taking more than a couple of minutes to start, please contact our support team (support@travis-ci.com) and we can look into it.

As for people testing Repositories on travis-ci.org, we have recently added further capacity which has helped reduce our backlog significantly. We are looking into some further changes and improvements which we will provide more information on in a blog post soon.

Thanks for your patience, and please don't be afraid to email us at support@travis-ci.com if you would like us to look into your particular account.

Josh

Member

joshk commented Mar 19, 2017

Hi Everyone

I'm sorry for the issues you have experienced with jobs taking a long time to start.

From some of the comments in this thread, I think there might be a confusion between travis-ci.org and travis-ci.com. I wanted to try and clear up some of this confusion, or at least try to understand it better :)

The Mac queues for travis-ci.org and travis-ci.com are separate in terms of provisioned capacity, but use the same underlying infrastructure. We make sure we have enough provisioned capacity for our customers on travis-ci.com who are testing private Repositories on our Mac infrastructure. For travis-ci.org we provide a greater capacity, in terms of concurrent VMs, but have had to make some hard decisions on how and when to increase this capacity as the cost for helping the open source community is fairly high.

If you are a customer on travis-ci.com and you find your jobs are taking more than a couple of minutes to start, please contact our support team (support@travis-ci.com) and we can look into it.

As for people testing Repositories on travis-ci.org, we have recently added further capacity which has helped reduce our backlog significantly. We are looking into some further changes and improvements which we will provide more information on in a blog post soon.

Thanks for your patience, and please don't be afraid to email us at support@travis-ci.com if you would like us to look into your particular account.

Josh

@AnthonyOliveri

This comment has been minimized.

Show comment
Hide comment
@AnthonyOliveri

AnthonyOliveri Mar 22, 2017

Thank you for the clarifications Josh. The Mac builds have been much quicker over the past few days, so it looks like the infrastructure changes have helped quite a bit. I'm still getting some delays but nowhere near as bad as it had been over the past several weeks.

Is anyone else still experiencing big delays in build start times?

Thank you for the clarifications Josh. The Mac builds have been much quicker over the past few days, so it looks like the infrastructure changes have helped quite a bit. I'm still getting some delays but nowhere near as bad as it had been over the past several weeks.

Is anyone else still experiencing big delays in build start times?

@BanzaiMan BanzaiMan added the mac label Mar 31, 2017

@portellaa portellaa referenced this issue in Mindera/Alicerce Apr 4, 2017

Closed

Rename travis and fix language #12

@shalunov shalunov referenced this issue in clostra/newnode Jun 9, 2017

Closed

CI takes 40 minutes to finish #53

@matteobachetti

This comment has been minimized.

Show comment
Hide comment
@matteobachetti

matteobachetti Jun 14, 2017

Hi,
Don't get me wrong, I love Travis and I love that it is free. So, nothing else than thanks.
However, the Mac OSX build does slow down the builds. It often starts when all other builds have finished, and it is the slowest build, so this almost doubles the build time. For the moment, I have set the OSX build as optional and I look at it by eye, this is not ideal but again... this is a free service, it's better than nothing and actually pretty awesome for Linux builds :)

Hi,
Don't get me wrong, I love Travis and I love that it is free. So, nothing else than thanks.
However, the Mac OSX build does slow down the builds. It often starts when all other builds have finished, and it is the slowest build, so this almost doubles the build time. For the moment, I have set the OSX build as optional and I look at it by eye, this is not ideal but again... this is a free service, it's better than nothing and actually pretty awesome for Linux builds :)

@alallier alallier referenced this issue in alallier/reload Jun 20, 2017

Closed

Add macOS CI #96

@lukeyeager lukeyeager referenced this issue in caffe2/caffe2 Jun 23, 2017

Closed

TravisCI: fix OSX builds #858

@parisk

This comment has been minimized.

Show comment
Hide comment
@parisk

parisk Jul 14, 2017

Hello,

We are experiencing the same issue at xterm.js.

An option for us would be disabling osx builds for all branches, but master. Is this something that can be configured?

I gave it a few tries with .travis.yml, but had no luck with it (latest .travis.yml).

parisk commented Jul 14, 2017

Hello,

We are experiencing the same issue at xterm.js.

An option for us would be disabling osx builds for all branches, but master. Is this something that can be configured?

I gave it a few tries with .travis.yml, but had no luck with it (latest .travis.yml).

@vazexqi vazexqi referenced this issue in forcedotcom/salesforcedx-vscode Jul 26, 2017

Merged

Activate test execution on Travis CI #16

@pkittenis

This comment has been minimized.

Show comment
Hide comment
@pkittenis

pkittenis Aug 17, 2017

Been trying to do the above at ssh2-python but it looks like the branches: only block only works when set globally and is ignored in either matrix or stages include blocks.

Been trying to do the above at ssh2-python but it looks like the branches: only block only works when set globally and is ignored in either matrix or stages include blocks.

@lucasbento

This comment has been minimized.

Show comment
Hide comment
@lucasbento

lucasbento Sep 5, 2017

Did anyone manage to do any workaround for it to get faster? I added a NodeJS project that runs on OSX, it's been 17 minutes and it didn't start yet.

Did anyone manage to do any workaround for it to get faster? I added a NodeJS project that runs on OSX, it's been 17 minutes and it didn't start yet.

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Sep 5, 2017

weitjong commented Sep 5, 2017

@spacejam

This comment has been minimized.

Show comment
Hide comment
@spacejam

spacejam Sep 8, 2017

I'd pay like $20/mo if it meant not waiting in queues for osx builds. This is the biggest reason I'm starting to look at alternative CI systems :(

spacejam commented Sep 8, 2017

I'd pay like $20/mo if it meant not waiting in queues for osx builds. This is the biggest reason I'm starting to look at alternative CI systems :(

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Sep 19, 2017

Hi there! We use travis-ci.org and we greatly appreciate this awesome free service! However given that mac builds can take in excess of 5 hours to start for us we'd like to only enable mac builds when we're concerned that a particular pull request might not work on mac. If travis-ci gave us the ability to only use mac builds on request per PR it would greatly speed up our iteration process. In addition to this it would likely reduce costs for travis-ci as we'd be generating significantly fewer OSX jobs.

Xaeroxe commented Sep 19, 2017

Hi there! We use travis-ci.org and we greatly appreciate this awesome free service! However given that mac builds can take in excess of 5 hours to start for us we'd like to only enable mac builds when we're concerned that a particular pull request might not work on mac. If travis-ci gave us the ability to only use mac builds on request per PR it would greatly speed up our iteration process. In addition to this it would likely reduce costs for travis-ci as we'd be generating significantly fewer OSX jobs.

@minggo

This comment has been minimized.

Show comment
Hide comment
@minggo

minggo Sep 20, 2017

The issue is not resolved. Take a look of this build, i restarted Mac build after waiting more than 4 hours to start, and it still being waiting.

minggo commented Sep 20, 2017

The issue is not resolved. Take a look of this build, i restarted Mac build after waiting more than 4 hours to start, and it still being waiting.

@NoahAndrews

This comment has been minimized.

Show comment
Hide comment
@NoahAndrews

NoahAndrews Sep 20, 2017

@minggo They're not going to "resolve" this issue for free users. It's too expensive.

@minggo They're not going to "resolve" this issue for free users. It's too expensive.

@weitjong

This comment has been minimized.

Show comment
Hide comment
@weitjong

weitjong Sep 21, 2017

I wonder if Travis should impose some kind of "road tax" system to ease the congestion. Perhaps a OSX quota system per open source project per day. Or simply separate the build queue for OSX and non-OSX (like I have proposed before above) so that at least the impact doesn't spill over to the rest of our build jobs. At the moment someone in our team has to constantly monitoring and manually killing our queued OSX build jobs in order to free up the slot for the next commit.

I wonder if Travis should impose some kind of "road tax" system to ease the congestion. Perhaps a OSX quota system per open source project per day. Or simply separate the build queue for OSX and non-OSX (like I have proposed before above) so that at least the impact doesn't spill over to the rest of our build jobs. At the moment someone in our team has to constantly monitoring and manually killing our queued OSX build jobs in order to free up the slot for the next commit.

@0intro 0intro referenced this issue in 9fans/plan9port Sep 21, 2017

Closed

builder #78

@uglym8 uglym8 referenced this issue in rdesktop/rdesktop Oct 6, 2017

Closed

Auto-build rdesktop for OS X through Travis CI #163

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 19, 2017

One idea is for someone write an app that uses the travis-ci API to cancel OSX builds that haven't yet started if there are any queued linux builds and then restarts all of the OSX builds that it cancelled after the linux queue is processed.

It's a good idea, but not something that I really have time to do myself.

ghost commented Oct 19, 2017

One idea is for someone write an app that uses the travis-ci API to cancel OSX builds that haven't yet started if there are any queued linux builds and then restarts all of the OSX builds that it cancelled after the linux queue is processed.

It's a good idea, but not something that I really have time to do myself.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 19, 2017

Actually, on second thought, the service wouldn't need to have any state (storage). You could just have something that looks at the builds and if linux builds are reduced from OSX usage, just cancel and restart the OSX builds, which will move them to the back of the line.

ghost commented Oct 19, 2017

Actually, on second thought, the service wouldn't need to have any state (storage). You could just have something that looks at the builds and if linux builds are reduced from OSX usage, just cancel and restart the OSX builds, which will move them to the back of the line.

@bpoplauschi

This comment has been minimized.

Show comment
Hide comment
@bpoplauschi

bpoplauschi Oct 20, 2017

@joshk really appreciate your response here (and of course the help you guys give to open source projects - it does help a lot).
I want to ask if someone on your end could take a look into why there are some many builds for Mac on travis-ci.org, is it the case that there are so many projects? Or some projects just have a big number of builds?
I'm a maintainer for two big Objective-C projects (SDWebImage and CocoaLumberjack with thousands of stargazers) and we are somehow impacted by this. I would lie saying we can't work, but waiting for up to an hour for every build to start is a bit problematic.
Maybe there could be some priority for projects used by many people as opposed to people just trying out Travis CI and playing with it. Just a thought.
Looking forward to your opinion.

@joshk really appreciate your response here (and of course the help you guys give to open source projects - it does help a lot).
I want to ask if someone on your end could take a look into why there are some many builds for Mac on travis-ci.org, is it the case that there are so many projects? Or some projects just have a big number of builds?
I'm a maintainer for two big Objective-C projects (SDWebImage and CocoaLumberjack with thousands of stargazers) and we are somehow impacted by this. I would lie saying we can't work, but waiting for up to an hour for every build to start is a bit problematic.
Maybe there could be some priority for projects used by many people as opposed to people just trying out Travis CI and playing with it. Just a thought.
Looking forward to your opinion.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 20, 2017

I have proposed a potential solution: #8615.

@BanzaiMan Could you post a link on your website so that people can donate for that? It might be worth it if enough people donate.

ghost commented Oct 20, 2017

I have proposed a potential solution: #8615.

@BanzaiMan Could you post a link on your website so that people can donate for that? It might be worth it if enough people donate.

@niboshi niboshi referenced this issue in chainer/chainer Oct 25, 2017

Closed

Disable MacOSX tests in Travis CI #3671

@Lange

This comment has been minimized.

Show comment
Hide comment
@Lange

Lange Nov 7, 2017

Just throwing in my two cents: I'd gladly pay a reasonable monthly fee to get faster OSX builds for my open-source projects and help support the Travis infrastructure. I consider Travis to be a crucial bit of public infrastructure, and I'd be willing to pay a "tax" to support it just as I do any other public infrastructure.

Lange commented Nov 7, 2017

Just throwing in my two cents: I'd gladly pay a reasonable monthly fee to get faster OSX builds for my open-source projects and help support the Travis infrastructure. I consider Travis to be a crucial bit of public infrastructure, and I'd be willing to pay a "tax" to support it just as I do any other public infrastructure.

@rraallvv

This comment has been minimized.

Show comment
Hide comment
@rraallvv

rraallvv Nov 10, 2017

Is there any chance to make macOS and iOS toolchains available on Linux? Maybe using something like cctools-port.

rraallvv commented Nov 10, 2017

Is there any chance to make macOS and iOS toolchains available on Linux? Maybe using something like cctools-port.

@guw guw referenced this issue in forcedotcom/salesforcedx-vscode Nov 15, 2017

Merged

Allow osx build to fail #178

@cptwonton cptwonton referenced this issue in TestingResearchIllinois/starts Nov 17, 2017

Closed

travisCI mac builds are slow to start #36

@robertmain

This comment has been minimized.

Show comment
Hide comment
@robertmain

robertmain Nov 21, 2017

I'm sure this has to do with Mac builds having to be run on real Mac hardware.

wait - so does this mean that travis-ci has an iMac somewhere just running builds?

I'm sure this has to do with Mac builds having to be run on real Mac hardware.

wait - so does this mean that travis-ci has an iMac somewhere just running builds?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 21, 2017

wait - so does this mean that travis-ci has an iMac somewhere just running builds?

Yes.

ghost commented Nov 21, 2017

wait - so does this mean that travis-ci has an iMac somewhere just running builds?

Yes.

@robertmain

This comment has been minimized.

Show comment
Hide comment

...wow.

@Xaeroxe

This comment has been minimized.

Show comment
Hide comment
@Xaeroxe

Xaeroxe Nov 21, 2017

Xaeroxe commented Nov 21, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 21, 2017

This is probably what it looks like:

Alt text

ghost commented Nov 21, 2017

This is probably what it looks like:

Alt text

@robertmain

This comment has been minimized.

Show comment
Hide comment
@robertmain

robertmain Nov 21, 2017

oh ok...i guess the form factor of that is a little more managable

@xoviat - thats cool.

oh ok...i guess the form factor of that is a little more managable

@xoviat - thats cool.

@jfurrow jfurrow referenced this issue in jfurrow/flood Nov 29, 2017

Merged

Add TravisCI config and make tests pass #563

4 of 9 tasks complete

@vazexqi vazexqi referenced this issue in forcedotcom/salesforcedx-vscode Dec 1, 2017

Merged

Update Build Infrastructure #225

@CAD97 CAD97 referenced this issue in rust-lang-nursery/rustfmt Dec 7, 2017

Merged

[Travis] Fix python/travis-cargo on macOS #2229

@mforets mforets referenced this issue in JuliaReach/MathematicalSystems.jl Dec 20, 2017

Merged

#1 - Constrained systems #3

@guruvan guruvan referenced this issue in mazaclub/EasyElectrumBuilder Jan 9, 2018

Open

OSX Travis build backlog borderline unusable #1

@abraham abraham referenced this issue in abraham/nutmeg-cli Jan 10, 2018

Merged

Remove TravisCI #154

@evandrocoan evandrocoan referenced this issue in heldev/sublime-lines-multisets Jan 14, 2018

Merged

Setup the unittesting.json, .travis.yml, appveyor.yml and their #1

@lildude lildude referenced this issue in github/backup-utils Jan 15, 2018

Merged

Remove Precise Travis CI builds #366

@danielbayley

This comment has been minimized.

Show comment
Hide comment
@danielbayley

danielbayley Jan 21, 2018

I wonder if https://veertu.com/anka-technology would be relevant here?

I wonder if https://veertu.com/anka-technology would be relevant here?

@breznak

This comment has been minimized.

Show comment
Hide comment
@breznak

breznak Jan 22, 2018

Still valid pain point, have to move our (free) project from Travis, will try CircleCI

breznak commented Jan 22, 2018

Still valid pain point, have to move our (free) project from Travis, will try CircleCI

@minggo

This comment has been minimized.

Show comment
Hide comment
@minggo

minggo Jan 23, 2018

Yep, it is very slow.
@breznak can CircleCI supports mac?

minggo commented Jan 23, 2018

Yep, it is very slow.
@breznak can CircleCI supports mac?

@rraallvv

This comment has been minimized.

Show comment
Hide comment
@rraallvv

rraallvv Jan 23, 2018

@minggo you might want to give Bitrise a try. It's free for macOS, and doesn't have that backlog problem.

@minggo you might want to give Bitrise a try. It's free for macOS, and doesn't have that backlog problem.

@minggo

This comment has been minimized.

Show comment
Hide comment

minggo commented Jan 23, 2018

Thanks @rraallvv .

@breznak

This comment has been minimized.

Show comment
Hide comment
@breznak

breznak Jan 23, 2018

can CircleCI supports mac?

@minggo for open source projects they do for free, for paid plan they of course do.

breznak commented Jan 23, 2018

can CircleCI supports mac?

@minggo for open source projects they do for free, for paid plan they of course do.

@Lyoness

This comment has been minimized.

Show comment
Hide comment
@Lyoness

Lyoness Jan 30, 2018

Member

Hello Everyone,

We (the build infra team) at Travis have been working hard to fix the performance problems of our macOS infrastructure, which meant we needed to focus all attention to migrating over to a new datacenter instead of optimizing for old hardware and SAN for better boot times. The migration finally was implemented last week. You'll notice that your builds no longer have wait times for private or open source projects, and build times network I/O --in addition to faster boot times-- have improved. We're still taking in comparison data to quantify just how much of an improvement, but we've hoped you've also noticed for yourselves. We're very happy (and relieved) to have finally shipped this. A blog post is forthcoming.

-Your Friendly Neighborhood Build Infrastructure Team at Travis

Member

Lyoness commented Jan 30, 2018

Hello Everyone,

We (the build infra team) at Travis have been working hard to fix the performance problems of our macOS infrastructure, which meant we needed to focus all attention to migrating over to a new datacenter instead of optimizing for old hardware and SAN for better boot times. The migration finally was implemented last week. You'll notice that your builds no longer have wait times for private or open source projects, and build times network I/O --in addition to faster boot times-- have improved. We're still taking in comparison data to quantify just how much of an improvement, but we've hoped you've also noticed for yourselves. We're very happy (and relieved) to have finally shipped this. A blog post is forthcoming.

-Your Friendly Neighborhood Build Infrastructure Team at Travis

@Lyoness Lyoness closed this Jan 30, 2018

@Xaeroxe Xaeroxe referenced this issue in amethyst/amethyst Jan 30, 2018

Merged

Start using OSX in travis #550

bors bot added a commit to amethyst/amethyst that referenced this issue Jan 31, 2018

Merge #550
550: Start using OSX in travis r=Xaeroxe a=Xaeroxe

Per travis-ci/travis-ci#7304 (comment) I believe we can turn this back on.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/amethyst/amethyst/550)
<!-- Reviewable:end -->

@emil-apeunit emil-apeunit referenced this issue in aeternity/aepp-identity Jun 21, 2018

Closed

feature/cordova #130

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment