Aaahh … well that’s a different thing … that’s already possible with maven :-)
Right now, all Apache releases go to a so-called release-repository. That’s a Maven repository containing only the artifacts of the current release. The project can vote on this. If the vote doesn’t pass, the repo is simply dropped and it was as if nothing had happened. If the release passes, the artifacts are released to the Apache Maven Release Repo and this is automatically mirrored to Maven Central. So, it seems this part is already taken care of … one more thing to check off the list ;-) I guess Travis was chosen, because Github was selected as primary repo for the project and the integration with auto-built pull requests is great, I have to admit that. But it is problematic to setup auto deployment of SNAPSHOT versions as we would have to check in credentials for deploying to the Apache Maven repo and that’s not going to happen. As the build setup is quite trivial I think using both is the best option. Use Travis for the auto-testing of pull-requests. Use Apache Jenkins for deploying SNAPSHOTS and doing code-analysis on Sonarqube and stuff like that. Right now, I am still having issues running all Tests in the java7 version … math3 is sort of causing issues, I haven’t quite figured out why. Chris Am 13.06.17, 15:59 schrieb "Dale LaBossiere" <[email protected]>: > On Jun 12, 2017, at 5:04 PM, Christofer Dutz <[email protected]> wrote: > ... > I guess also executing the pre-built test with java7 should also be possible, but I’m struggling with one other of your requirements: > “Only deploy everything if the java8, java7 and android builds succeed”. I hope you can see the dilemma. It’s possible my terminology is confusing/inaccurate. Mostly I think I meant that for releases (not talking about snapshots nor release-candidate staging for voting) we should only make the final release artifacts, including convenience binaries, public only if/once all configurations have passed testing&voting. I think it’s time for me to go back to all the ASF release doc info. I know a lot has changed and earlier I didn’t pay any attention to snapshots nor maven related things because we weren’t doing them. > Here it might be a better option to add a Jenkinsfile to the repository and setup a Jenkins job on the ASF Jenkins. With this I am a lot more flexible than with Travis. We could continue to use Travis for the auto-testing of pull requests, but would live with running the java7 testsuite with a java8 VM, but have the Jenkins job deploy the SNAPSHOTS to the ASF repo. > > What do you think about that? Building on Apache Machines also gives a lot of other benefits. I don’t know why Travis was chosen. Is the ASF Jenkins service relatively new or not good/viable for PR-auto-test use? Regardless, partially or fully switching to Jenkins tooling as appropriate is OK with me - unless there are some things you forgot to mention :-) — Dale
