is it possible to deploy the Java jar-files (sources and "normal") to the
official maven-repo after a successful build, meaning no test failures...?
That would be great :-)
2012/9/21 Johannes Lichtenberger <lichtenberger.johan...@gmail.com>
> is it possible to deploy the Java jar-files (sources and "normal") to the
> official maven-repo after a successful build, meaning no test failures...?
> That would be great :-)
No. There may be a way to accomplish that with secure env variables fairly
soon but nothing to date.
-- MK
> No. There may be a way to accomplish that with secure env variables fairly > soon but nothing to date.
I thought about that, too. Maybe not pushing release versions to Central (in my case through Sonatype OSSRH), but SNAPSHOT versions on every commit. Of course, you could also push release versions when creating a git tag.
So, what we need to do is first adding a <server> entry to ~/.m2/settings.xml which has your username and password of the repository. Then the ssh-agent must be running and our private gpg key loaded (by optionally providing a password) for signing the jars. And then, for snapshots you would run "mvn clean deploy" and for releases it would be "mvn release:clean", "mvn release:prepare", "mvn release:perform" followed by some goals of the nexus maven plugin for closing and promoting.
I think it could be done although it requires some initial work. The tricky part would be to store all private data in secure env variables, let a shell script read and write them to files and then run the maven goals. That would be really cool.
This would be really great to have! Just an idea... To implement it, it may be easier to start just with username/password first (to be added to the m2 settings.xml), which would allow deploying snapshots already. In this way GPG infrastructure is not needed yet...
On Sunday, October 28, 2012 5:49:37 PM UTC, Maik Riechert wrote:
> Michael Klishin wrote:
>> No. There may be a way to accomplish that with secure env variables >> fairly soon but nothing to date.
> I thought about that, too. Maybe not pushing release versions to Central > (in my case through Sonatype OSSRH), but SNAPSHOT versions on every commit. > Of course, you could also push release versions when creating a git tag.
> So, what we need to do is first adding a <server> entry to > ~/.m2/settings.xml which has your username and password of the repository. > Then the ssh-agent must be running and our private gpg key loaded (by > optionally providing a password) for signing the jars. And then, for > snapshots you would run "mvn clean deploy" and for releases it would be > "mvn release:clean", "mvn release:prepare", "mvn release:perform" followed > by some goals of the nexus maven plugin for closing and promoting.
> I think it could be done although it requires some initial work. The > tricky part would be to store all private data in secure env variables, let > a shell script read and write them to files and then run the maven goals. > That would be really cool.
Rintcius Blok wrote:
> To implement it, it may be easier to start just with username/password > first (to be added to the m2 settings.xml), which would allow > deploying snapshots already.
This appends the server entry to the settings.xml where username and password are read from the environment varsSONATYPE_USERNAME andSONATYPE_PASSWORD.
I downloaded the JVM base box and tried to test it locally but I had some problems accessing the env vars (that I set manually) when sudoing. I need to run the script as sudo because the settings.xml is owned by root with group root and has permissions rw-r--r--. I don't know if this issue will appear in actual builds. Any advice?
> I downloaded the JVM base box and tried to test it locally but I had some
> problems accessing the env vars (that I set manually) when sudoing. I need
> to run the script as sudo because the settings.xml is owned by root with
> group root and has permissions rw-r--r--.
We can change that.
> I don't know if this issue will appear in actual builds. Any advice?
sudo resets env variables to a few whitelisted ones. We won't add these
variables to the white list but changing permissions to 664 and
owner to "travis" is a good idea.
> sudo resets env variables to a few whitelisted ones. We won't add > these variables to the white list but changing permissions to 664 and
> owner to "travis" is a good idea.
Question about the encrypted password that is stored in travis.yml: is that going to be safe to store there? (I mean travis needs to be able to decrypt the password and use it, but everyone else must NOT be able to do that. Since travis is opensource I don't see how that can be achieved easily) In my mind, I thought the password would be stored somewhere private (like via the GUI).
I am very new to travis though, so it's very well possible that I am missing something. Can someone explain how it will work?
On Monday, November 12, 2012 8:02:16 PM UTC, Maik Riechert wrote:
> Michael Klishin: > > sudo resets env variables to a few whitelisted ones. We won't add > > these variables to the white list but changing permissions to 664 and > > owner to "travis" is a good idea. > Great! I added the second part: > https://gist.github.com/4060735#file_.travis.yml
> I think with that it should already work. Please leave a note once the > permission change is rolled out.
Any News on the permission change? I actually ran into the same problem that the settings.xml is not writable by the python script provided by Maik (great work btw, thx!).
Would be cool to finally automate the process pushing our builds to our nexus repo.
Am Montag, 12. November 2012 19:10:45 UTC+1 schrieb Michael Klishin:
>> I downloaded the JVM base box and tried to test it locally but I had some >> problems accessing the env vars (that I set manually) when sudoing. I need >> to run the script as sudo because the settings.xml is owned by root with >> group root and has permissions rw-r--r--.
> We can change that.
>> I don't know if this issue will appear in actual builds. Any advice?
> sudo resets env variables to a few whitelisted ones. We won't add these > variables to the white list but changing permissions to 664 and > owner to "travis" is a good idea.
> Any News on the permission change? I actually ran into the same problem > that the settings.xml is not writable by the python script provided by Maik > (great work btw, thx!).
> Would be cool to finally automate the process pushing our builds to our > nexus repo.
> Am Montag, 12. November 2012 19:10:45 UTC+1 schrieb Michael Klishin:
>>> I downloaded the JVM base box and tried to test it locally but I had >>> some problems accessing the env vars (that I set manually) when sudoing. I >>> need to run the script as sudo because the settings.xml is owned by root >>> with group root and has permissions rw-r--r--.
>> We can change that.
>>> I don't know if this issue will appear in actual builds. Any advice?
>> sudo resets env variables to a few whitelisted ones. We won't add these >> variables to the white list but changing permissions to 664 and
>> owner to "travis" is a good idea.
> That's it, works like a charm! Thanks a lot guys!
> Am Freitag, 14. Dezember 2012 22:47:36 UTC+1 schrieb Björn Teichmann:
> Any News on the permission change? I actually ran into the same
> problem that the settings.xml is not writable by the python script
> provided by Maik (great work btw, thx!).
> Would be cool to finally automate the process pushing our builds
> to our nexus repo.
> Am Montag, 12. November 2012 19:10:45 UTC+1 schrieb Michael Klishin:
> I downloaded the JVM base box and tried to test it locally
> but I had some problems accessing the env vars (that I set
> manually) when sudoing. I need to run the script as sudo
> because the settings.xml is owned by root with group root
> and has permissions rw-r--r--.
> We can change that.
> I don't know if this issue will appear in actual builds.
> Any advice?
> sudo resets env variables to a few whitelisted ones. We won't
> add these variables to the white list but changing permissions
> to 664 and
> owner to "travis" is a good idea.
