Boost.CI for Boost Repository Build Quality
Continuous Integration is a modern cornerstone of delivering quality results in software engineering. When I started getting involved in boost as a maintainer (instead of a long-time consumer) it became a goal to get CI into as many repositories as possible. CI allows submitters to self-check their code changes without bothering the maintainer(s) of each repository. It eases the burden for maintainers as they can focus more on code review, and less on manual machinations to validate changes (by running code locally in their own environments). The wide coverage of builds in Boost.CI has helped identify a number of issues and improved the quality of those repositories. Performing these tests and analyses before code is merged catches issues earlier (but is not as comprehensive as the test matrix in terms of platform support due to limitations in the CI providers). Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location. https://github.com/jeking3/boost-ci Thanks, Jim
On Mon, 5 Nov 2018 at 14:35, James E. King III via Boost
[...] Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location.
AFAICT, there is no support for AppVeyor Linux builds. Any reason behind that? I think AppVeyor Linux could be a useful alternative or complementary Linux-based service. Especially that Travis CI for boostorg are is permanently unresponsive due to long running builds of certain, if not most, Boost libraries. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Mon, Nov 5, 2018 at 9:07 AM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:
AFAICT, there is no support for AppVeyor Linux builds. Any reason behind that?
I think AppVeyor Linux could be a useful alternative or complementary Linux-based service. Especially that Travis CI for boostorg are is permanently unresponsive due to long running builds of certain, if not most, Boost libraries.
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
I'm not trying to imply or state that this is something that must be used everywhere. It's been tremendously helpful and is being used on 20+ boost repositories already. Therefore I think it should be pulled into boostorg as the "owner". Apart from that: What would AppVeyor provide that Travis does not, other than the timeout issue? I agree, I've seen what you are talking about with the timeouts. I would say any build that takes over 50 minutes is too long and should be broken up or optimized or simplified somehow anyway. Also, AppVeyor has some deficiencies: - In AppVeyor I get one concurrent job. In Travis I get 5. - In AppVeyor I cannot restart an individual job that is part of a suite of builds in a PR. In Travis I can. - Jim
On Mon, 5 Nov 2018 at 17:30, James E. King III
On Mon, Nov 5, 2018 at 9:07 AM Mateusz Loskot via Boost
wrote: AFAICT, there is no support for AppVeyor Linux builds. Any reason behind that?
I think AppVeyor Linux could be a useful alternative or complementary Linux-based service. Especially that Travis CI for boostorg are is permanently unresponsive due to long running builds of certain, if not most, Boost libraries.
I'm not trying to imply or state that this is something that must be used everywhere. It's been tremendously helpful and is being used on 20+ boost repositories already. Therefore I think it should be pulled into boostorg as the "owner".
Apart from that: What would AppVeyor provide that Travis does not, other than the timeout issue?
AFAIK, it does not provide anything different or better than to Travis. For me, - it is a spare check that allows me to ignore Travis (long) pending jobs - it is there, it i savailable, so why not to use it For Boost GIL, Geometry, CircleCI plays an important role too.
I agree, I've seen what you are talking about with the timeouts. I would say any build that takes over 50 minutes is too long and should be broken up or optimized or simplified somehow anyway.
Or divide: set A on Travis, set B on AppVeyor, then sum of the checks means healthy PR, etc. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
James E. King III wrote:
Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location.
If you transfer the repository to me, I'll transfer it to boostorg.
participants (3)
-
James E. King III
-
Mateusz Loskot
-
Peter Dimov