Jenkins builds are used AFAIK (but likely most of them by people doing $upport on older versions ;)) Personally I only use master but if you want to start a cleanup thread +1.
It also seems unlikely we get PR support on jenkins from my understanding - if wrong it would be awesome - this is why I think we should enable PR somehow now. Now just a small note on travis vs gh actions and why I don't defend travis*.org* much: gh actions - gh link is highly unlikely to break with gh actions (compared to the link with travis which can and do) and travis.org is no more maintained since years (can break any day and the best the support will do is to ask you to move to travis.com, often for free for OSS but still), so it is likely a best bet *today* to support gh actions than it was last time to support travis IMHO (yes suffered a bit from travis*.org* last years). Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 17 juil. 2020 à 16:31, Francesco Chicchiriccò <ilgro...@apache.org> a écrit : > On 17/07/20 16:19, Enrico Olivelli wrote: > > Il Ven 17 Lug 2020, 16:14 Romain Manni-Bucau <rmannibu...@gmail.com> ha > > scritto: > > > >> Hi Enrico, > >> > >> While we have a single type of this build tool +1 (= I don't think it > would > >> be good to have GH Action + Travis + AppVeryor + SemaphoreCI + ...). > >> What would do the default build? mvn install or would it run all DB > >> profiles based on docker images? > > Just mvn install is enough for me. > > > > More complex/heavier builds should stay on ASF Jenkins, no need to run > them > > at every PR validation. > > Hi, > chiming in just to remember that we already had such discussion [1], that > we don't have Travis CI set up currently (I have it on my own fork, though: > [2]) and that we have a whole set of (mostly useless?) builds set up at ASF > Jenkins: [3]. > > Anyway, +1 to GitHub actions for PR validation. > > Regards. > > [1] > https://lists.apache.org/thread.html/82739677363b480e0913496ccd33e449625052e821f4b0275f6101c6%40%3Cdev.openjpa.apache.org%3E > [2] https://github.com/ilgrosso/openjpa/blob/master/.travis.yml > [3] https://builds.apache.org/view/M-R/view/OpenJPA/ > > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >> > >> Le ven. 17 juil. 2020 à 15:54, Enrico Olivelli <eolive...@gmail.com> a > >> écrit : > >> > >>> Hey, > >>> what about adding a simple validation of Pull Requests using GitHub > >> actions > >>> ? > >>> I can create a very simple configuration file if you like this idea. > >>> > >>> It will help a lot in contributing patches, this way it is sure for the > >>> committer that the patch is not breaking unit tests (not integration > >> tests, > >>> of course) and it can help the contributor as it given an immediate > >>> feedback of the goodness of the patch > >>> > >>> > >>> Enrico > >>> > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ > >
