Hi, I don't mind using a different service, but let me point out the build currently consumes quite some resources (and is likely to consume more in the future[1]). I believe ASF is contributing to Travis, so that there are more concurrent builds available on Travis for us[2]. We should check that whatever other service we use, we can still test in reasonable time. Also, I would not want to test less - we should rather test more, to improve stability.
[1] https://github.com/apache/netbeans/pull/2121 [2] https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci Jan On Sun, May 24, 2020 at 2:05 PM Hector Espert <[email protected]> wrote: > Hi everybody. > > I would like to open a discussion about with continuous integration service > we should use. > > > I like Travis CI, but after deal with it in the Netbeans project, I start > to think that they aren't a good couple. > > There are two Travis CI limits that are a pain in the neck, the log length > limit and the job limit to 50 min. I found that is a common problem and > other Apache projects are migrating his pipelines from Travis or are > thinking about that. > > > https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI > > > I would like to suggest two options. > > First , the most conservative option, migrate TravisCI pipeline to the > Apache Jenkins infrastructure. > > The problem that i see with this option is if we can integrate the Apache > Jenkins infrastructure with GitHub to run the test suite for every > PR/commits and show the results in the GitHub ui. > > The other option, is start to test with the GitHub workflows and if they > are better than TravisCI move to use GitHub workflows instead TravisCI. >
