Okay, so I've got my account setup on the Apache Hudson instance. I've also setup some struts builds. If you want to take a look, they are running here -
http://hudson.zones.apache.org/hudson/view/Struts/ Right now, these builds are pretty much a vanilla setup. They are not publishing snapshots or nightlies anywhere, they are building, so it's like a "first step." Anyhow, there are a few items I want to get feedback on. First off, if anyone wants to help out and/or be able to manage/change these builds you'll have to request an account on Hudson. The process is painless, more info here - http://wiki.apache.org/general/Hudson Now, my first question is more general. Hudson allows a few different triggers for launching builds. Right now, I'm telling it to check SVN once a day for changes. To me, this is sufficient, but not quite as comprehensive as Bamboo. I'm thinking that since this is a shared resource (and we're new to the neighborhood) I don't want to tax the system with full builds as frequently as bamboo was getting hit. Does anyone disagree with that frequency? Next, I am currently doing what amounts to a `mvn -Pall clean install` in the struts1 and struts2 directories. This give quite a few more artifacts than the currently nightly builds. But, this does not include the sandbox or maven. You'll notice there are two artifacts being built from the maven directory, but these are both necessary for the struts1/struts2 builds. I have nothing against adding more, but wanted to start with the main builds and add others if requested. Any others that people think we need? Also, there are quite a few options for publishing, post-build. I was thinking I would get this feedback and make any necessary changes to the builds before I consider pushing the build results out into the world. I am considering using the previous nightly builds as a model for where the artifacts go. Any suggestions or concerns on this? Lastly, since Musachy worked really hard to get the release process documented and easily(at least easier) repeatable, he enhanced the assembly module to zip up and grab the docs. I tried to help him with this while he was working on it and we noticed quite a few gotchas. First off, we already brought up that it is a nightly cron job to zip up the confluence export. So, the assembly tries to wget them. This isn't really optimum, since it runs as Ted and Ted must be really busy, so we couldn't make changes to the job (or see if/why it was failing from 2.1.3-2.1.6). My thought was to just use wget to mirror 2.x/docs/ and then zip as part of the assembly process. Not quite optimum, but doesn't tax mino every night. But, the problem with this was that wget honors the new robots.txt file which means wget refuses to pull it down. The current solution is to ssh over to people and call the zip-it-up script (which is /www/struts.apache.org/2.x/zip-docs2.sh, in case it's not documented elsewhere). This way, the zip happens when we need it to. Now, the downside to this is that if you do a `mvn -Pall clean install` in the struts2 directory, this will run. The first problem with that is that on the Building from source page in the docs, we tell users to do this. Of course, it will fail since you have to have your ssh setup to log into people.a.o. The next problem is for me trying to run this in Hudson. My first thought was that I could skip this task, but then, the assembly is a great way for me to generate nightlies, and it is sort of a matter of eating our own dogfood. If the assembly doesn't do what we want, we should make it do what we want... Anyhow, thoughts? -Wes --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
