> 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
