I'm not objecting per se, but I dont see particular benefits to doing so. I said when introducing the GitHub Actions build that I actually do see benefits to still running both, that remains true.
- Additional test runs are useful for spotting sporadic failure issues creep in, and in seeing them go away. - They can also be used to cover different OS / JDK versions etc without lumping all jobs/load on a single service. Right now they match as that was quick for me to set up. - Different hardware/envs can sometimes help spot issues. - The CI services tend to fall over now and then, but typically at different times, so it's nice not being reliant on just one. (I kid you not, while I typed this, I got a mail saying a GitHub Actions sub job run on my fork from earlier was cancelled because it took 6 hours, lol) Personally I prefer having more CI envs than less, e.g for some other projects I also have jobs running on the ASF Jenkins instance and Appveyor in addition to Travis and GitHub Actions. I dont think they dont take much at all to maintain, which would be the main reason I'd see for getting rid of them. On Tue, 22 Sep 2020 at 17:03, Justin Bertram <jbert...@apache.org> wrote: > > Quite a while back we started using Travis CI to run the PR builds for > Artemis. Recently support was added for GitHub Actions which run the same > builds as Travis CI. At this point, both Travis and GitHub are running the > same builds for Artemis PRs. > > Does anybody object to removing Travis builds? The GitHub Actions always > run faster and integration is better. I don't see any reason to run the > same builds on two different services. > > > Justin
