Hey All, So sorry for dropping the ball on this one for so long. I had meant to get back up to it, but job changes, etc. So yada yada, I have a newer version of this script which will actually checks out the latest launchpad and executes the launchpad integration tests correctly against it.
I'm not sure it makes sense from a Jenkins perspective, but as a pre-release step, it's a great thing to verify before putting things up to vote (and to verify votes). The idea is pretty simple, you call something like: ./build_staged_release.sh [staging_number] and it will automatically: - Checkout the latest launchpad to your /tmp directory - Build the staged code - Attempt to install it into Sling if it is a bundle - Execute the launchpad integration tests - Display the results and prompt you to shutdown Sling or keep it running in the background (and give you the PID) You can check out the script here: https://github.com/ klcodanr/sling/blob/tooling-improvements/build_staged_release.sh or test it against a currently open release with: ./build_staged_release.sh 1723 Please note that there is currently an issue with the launchpad integration tests. I have started another thread about that. The only thing that's a bit tricky is multi-module releases. There's a way to specify the order of the artifacts to build with the -o flag(ex: ./build_staged_release.sh 1234 -o org.apache.sling.commons.classloader,org.apache.sling.scripting.jsp). If we want to use this for release testing, I'd suggest whoever creates the release should probably specify in what order the bundles should be built. I also created another script for testing a particular scenario where you have code that you're trying to test which affects several different interrelated bundles. The idea is that you put the project & bundle you are looking to test in a text file in a format such as: bundles/scripting/jsp;org.apache.sling.scripting.jsp-2.3.1-SNAPSHOT.jar bundles/commons/classloader;org.apache.sling.commons. classloader-1.4.1-SNAPSHOT.jar The script will then read the file, install the bundles into a running sling instance, executes the integration tests and will prompt you whether you want to leave Sling running or shut it down. Very nice compared to having to separately build 3+ bundles and execute the tests manually or build the whole damn reactor for every code change you want to test. You can check that script out here: https://github.com/ klcodanr/sling/blob/tooling-improvements/test_build.sh Hopefully, others find these useful. If so I'd be more than happy to add them in. -Dan On Wed, Apr 22, 2015 at 3:07 AM, Bertrand Delacretaz <[email protected] > wrote: > On Tue, Apr 21, 2015 at 6:07 PM, Daniel Klco <[email protected]> > wrote: > > ... the problem I ran into earlier was how to ensure that > > the Sling instance has the latest code, not just the particular thing > being > > built. Right now, I'm just using Maven to fetch the latest snapshot > build... > > So you want a launchpad that uses all the latest snapshots for its bundles? > > If yes we've been discussing this a few times already, we might need > two launchpads, one with the latest bleeding edge stuff for testing, > and another more stable one using releases for application developers. > > Manipulating version numbers at the provisioning model should allow us > to do that. > > -Bertrand >
