edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Understanding the snapshot and release process
Date Tue, 13 Jun 2017 14:16:22 GMT
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.


Am 13.06.17, 15:59 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:

    > On Jun 12, 2017, at 5:04 PM, Christofer Dutz <christofer.dutz@c-ware.de> 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
    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

View raw message