Purchasing Travis Resources for boostorg (was Re: [1.65.0] Point release?)
On Sat, Aug 26, 2017 at 1:16 PM, Daniel James via Boost < boost@lists.boost.org> wrote:
On 26 August 2017 at 18:02, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Daniel James wrote:
But we don't rely that much on the testers nowadays, so this would be less of an issue.
I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
While I'm a big fan of Boost's test system, and believe that it is an awesome resource that can't be replicated on the common CI services (lots of platforms and compiler versions/configs!), I also think that good per-commit CI on a service like travis is hugely important. Maybe someone should present a proposal to the steering committee to start paying for boostorg's account to have additional build resources? Tom
On Sun, Aug 27, 2017 at 7:21 AM, Tom Kent via Boost <boost@lists.boost.org> wrote:
On Sat, Aug 26, 2017 at 1:16 PM, Daniel James via Boost < boost@lists.boost.org> wrote:
On 26 August 2017 at 18:02, Peter Dimov via Boost <boost@lists.boost.org
wrote:
Daniel James wrote:
But we don't rely that much on the testers nowadays, so this would be less of an issue.
I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
While I'm a big fan of Boost's test system, and believe that it is an awesome resource that can't be replicated on the common CI services (lots of platforms and compiler versions/configs!), I also think that good per-commit CI on a service like travis is hugely important. Maybe someone should present a proposal to the steering committee to start paying for boostorg's account to have additional build resources?
FYI.. OSS Travis gives out 5 concurrent jobs. Which you can compare with their paid plans: <https://travis-ci.com/plans>. -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
I've not found it a problem at all, turnaround is within five minutes almost all of the time. OS X is the only service which lags a bit certain times of the day. You shouldn't be working directly with boostorg repos, those get throttled at the boostorg level. You should work with your personal fork of the boostorg repo, that gets its own allocation of resources separate to boostorg. Also, if you're still using the VM-based service, it's going to lag. You want the container-based service (`sudo: false`), much quicker. And don't forget that travis can cache its init nowadays, so instead of spending twenty minutes building Boost from source, just cache the prebuilt filesystem tree and restore it next time Travis runs. Much faster. And finally the Trusty based images appear to run quicker than the Precise images. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 27 August 2017 at 14:53, Niall Douglas via Boost <boost@lists.boost.org> wrote:
I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
I've not found it a problem at all, turnaround is within five minutes almost all of the time. OS X is the only service which lags a bit certain times of the day.
You shouldn't be working directly with boostorg repos, those get throttled at the boostorg level. You should work with your personal fork of the boostorg repo, that gets its own allocation of resources separate to boostorg.
Pull requests are tested on boostorg.
On Sun, Aug 27, 2017 at 7:12 AM, Daniel James via Boost <boost@lists.boost.org> wrote:
Pull requests are tested on boostorg.
1. Authors can do pull requests against develop and master in their own forks 2. If no one worked in topical branches directly in boostorg repos, there would be much more CI bandwidth available for third party pull requests made against boostorg repos
On 27 August 2017 at 16:20, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Sun, Aug 27, 2017 at 7:12 AM, Daniel James via Boost <boost@lists.boost.org> wrote:
Pull requests are tested on boostorg.
1. Authors can do pull requests against develop and master in their own forks
Here's a pull request I created: https://github.com/boostorg/beast/pull/709 I created it from a fork. Click on the little green tick: https://travis-ci.org/boostorg/beast/builds/259865444?utm_source=github_status&utm_medium=notification It was tested on boostorg. We need a central place for people to create pull requests - they can't be expected to track down the correct account for individual repos.
2. If no one worked in topical branches directly in boostorg repos, there would be much more CI bandwidth available for third party pull requests made against boostorg repos
Most developers want to integrate their changes into develop regularly. That way their changes get shared amongst other developers, and enter into the testing system, so problems on more obscure platforms get found earlier, and problems that the changes cause other libraries can be detected. It also means more of the historical test results appear in the boostorg repo. For what it's worth, I do all of my development on branches in forks, but we also have to work with the boostorg organisation as a collaborative location. We already have enough problems tracking changes in different libraries, making it harder is a bad idea.
On Sun, Aug 27, 2017 at 10:09 AM, Daniel James via Boost <boost@lists.boost.org> wrote:
On 27 August 2017 at 16:20, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Sun, Aug 27, 2017 at 7:12 AM, Daniel James via Boost <boost@lists.boost.org> wrote:
Pull requests are tested on boostorg.
1. Authors can do pull requests against develop and master in their own forks
Here's a pull request I created:
https://github.com/boostorg/beast/pull/709
I created it from a fork. Click on the little green tick:
It was tested on boostorg.
We need a central place for people to create pull requests - they can't be expected to track down the correct account for individual repos.
2. If no one worked in topical branches directly in boostorg repos, there would be much more CI bandwidth available for third party pull requests made against boostorg repos
Most developers want to integrate their changes into develop regularly. That way their changes get shared amongst other developers, and enter into the testing system, so problems on more obscure platforms get found earlier, and problems that the changes cause other libraries can be detected. It also means more of the historical test results appear in the boostorg repo.
For what it's worth, I do all of my development on branches in forks, but we also have to work with the boostorg organisation as a collaborative location. We already have enough problems tracking changes in different libraries, making it harder is a bad idea.
I don't think anyone was proposing not to have develop on boostorg, I think they were proposing not having 5000 branches of new features actively under development on boost. Authors can make their local tests/commits to develop/test a feature on their account and then push that feature to the develop branch on boostorg. Develop should be for testing of features before they find their way into master anyway. If I am working on a new feature/bugfix I don't want to be working on someones ultra-unstable personal branch.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gary Furnish wrote:
I don't think anyone was proposing not to have develop on boostorg, I think they were proposing not having 5000 branches of new features actively under development on boost.
That's not a problem we're having at the moment. Our immediate blocker last time I took a look were the pull requests against boostorg/math. Math had many OS X jobs, which were taking quite a while.
On 27/08/2017 18:02, Peter Dimov via Boost wrote:
Gary Furnish wrote:
I don't think anyone was proposing not to have develop on boostorg, I think they were proposing not having 5000 branches of new features actively under development on boost.
That's not a problem we're having at the moment. Our immediate blocker last time I took a look were the pull requests against boostorg/math. Math had many OS X jobs, which were taking quite a while.
Ugh, sorry. If that's the blocker I'll see if I can whittle them down: part of the issue is that the full Math tests take too long to run as one block, so they're actually split into 5 blocks. BTW, we already have a fine array of volunteer testers, is there any way of setting up our own private CI system - is the software used by Travis and Appveyor open source? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
27.08.2017 15:21, Tom Kent via Boost пишет:
On Sat, Aug 26, 2017 at 1:16 PM, Daniel James via Boost < boost@lists.boost.org> wrote:
On 26 August 2017 at 18:02, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Daniel James wrote:
But we don't rely that much on the testers nowadays, so this would be less of an issue. I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
While I'm a big fan of Boost's test system, and believe that it is an awesome resource that can't be replicated on the common CI services (lots of platforms and compiler versions/configs!), I also think that good per-commit CI on a service like travis is hugely important. Maybe someone should present a proposal to the steering committee to start paying for boostorg's account to have additional build resources?
Tom
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Here you can see some results about using Travis CI additionally to Boost's test system: https://travis-ci.org/ZaMaZaN4iK/boost_indirect_testing
participants (9)
-
Alexander Zaitsev -
Daniel James -
Gary Furnish -
John Maddock -
Niall Douglas -
Peter Dimov -
Rene Rivera -
Tom Kent -
Vinnie Falco