In linux I've been using the screen command like this:
screen java -jar hudson.war --httpPort=9090
Then detaching and letting it run. Running it like this is useful if
auto update doesn't work and a manual restart is required.
Google seems to show that the 'screen' command also exists for FreeBSD
which would make this setup easy.
The big space use when using maven is that all the dependencies are
downloaded into ~/.m2/repository of the user running maven. Also when
the maven deploy goal is run all of the artifacts will be installed into
the local repository aswell.
My wicketstuff core hudson jobs don't archive artifacts in hudson (this
lets the build history be longer) but periodically the ~/.m2/repository
directory needs to be cleared out to reclaim space and manual access is
useful for this.
The oss.sonatype.org CI username/password need to be placed into the
~/.m2/settings.xml for the user running hudson.
By default hudson runs on port 8080 but using the --httpPort option it
can be run on any port. Probably there is a way to set the host aswell
so that it could be forced onto 127.0.0.1 and then the apache interface
would be the only way to access it.
In terms of access control there is the option to require users to
specify a username/password and then assign appropriate rights to each
user. I think the power to create users can also be delegated. This
would prevent anyone from shutting down the server unless they had the
access to do it.
I checked and Hudson when run this way uses the: Winstone Servlet Engine
v0.9.10
The actual hudson configuration and job configuration files are located
by default in the ~/.hudson directory I would be able to create a
starting point for this directory with the suitable access controls
enabled and provide it with the installation steps to the person with
wicketstuff.org server access. That way it could be deployed in a
secure way without risk of tampering before it is setup properly.
Regards,
Mike
Here are the instructions for setting it up on linux/unix:
http://wiki.hudson-ci.org/display/HUDSON/Installing+Hudson#InstallingHudson-Unix%2FLinuxInstallation
You *can* just do:
java -jar hudson.war
and it'll run. That's just a quick way to get it up and running to
play around with it.
On Wed, Jul 21, 2010 at 9:11 AM, Johan Compagner<jcompag...@gmail.com> wrote:
how do you deploy then?
has hudson its container (tomcat)??
Then we also need another port. And have all kind of apache config to
support things like:
wicketstuff.org/hudson
hmm that i dont like. It should just run on the tomcat instance we have.
On Wed, Jul 21, 2010 at 14:51, Martijn Dashorst
<martijn.dasho...@gmail.com> wrote:
Security needs to be enabled and other stuff. Deploying as a war does
have some drawbacks: restarting using the UI won't work,
installing/updating plugins/new versions of hudson is enabled by
default.
Martijn
On Wed, Jul 21, 2010 at 2:46 PM, Johan Compagner<jcompag...@gmail.com> wrote:
hudson is just a war right?
so that can be dumped by anybody of the wicket devs to onto the tomcat
webapp dir.
What more does hudson need?
On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst
<martijn.dasho...@gmail.com> wrote:
My little bird told me that no build server is part of the new deal
which is slated to be announced mid-august, so IMO we should not delay
the migration off of teamcity and setup hudson. I'll contact the
sysadmin for the box to see if I can grant direct access, or that only
"trusted" folks are allowed.
Martijn
On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst
<martijn.dasho...@gmail.com> wrote:
There are some developments unfolding in the near future that might
help out on the future of our wicketstuff server and/or its
infrastructure. I don't have the full details to those plans yet, and
don't know if they entail a build server of some sorts.
I'm perfectly happy with switching to hudson—we use it at work and it
has been a godsend compared to the other available solutions (though I
still don't like the UI).
I hope we can wait a (couple of) week(s) and see the future plans
unfold to see what the details are, especially with respect to a build
server. I'll ask around to see if it is part of that deal.
Martijn
On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh
<michael.ocleir...@rivulet.ca> wrote:
Hello,
I've been using Hudson reliably to build wicketstuff core snapshot's and
deploying them into the sonatype maven repository. I put together an older
machine for this purpose (P4 1.8Ghz) and while it worked at first recently
there have been memory issues (at least one of the DDR1 DIMM's is bad and
the JVM keeps crashing). I have the builds running temporarily somewhere
else but the long term solution is to run Hudson on a box that can be opened
up to the other wicketstuff developers.
My proposal is to replace TeamCity on wicketstuff.org with Hudson and then
do the necessary setup to allow wicketstuff developers access to it for
initiating builds and viewing the projects status.
I am willing to do all of the necessary setup and configuration to make this
happen; basically copying over what I have working right now plus adding in
user authentication.
The easiest way would be if I could get a user account on the
wicketstuff.org server (at least initially) and then get everything setup.
There are still some questions around if the wicketstuff.org box is still
banned by sourceforge but I think the best way to find out the answer is to
try and see what happens.
Regards,
Mike
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
