Note I'm not saying you need to wait for all the build services to complete before e.g merging a PR. If any one is finished, by all means merge away.
On Tue, 22 Sep 2020 at 17:48, Robbie Gemmell <[email protected]> wrote: > > 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 <[email protected]> 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
