Re: [wtp-releng] CBI build planning - meeting notes

[Mickael Istria <mistria@xxxxxxxxxx>]

Hi,

On 01/09/2014 05:19 AM, Carl Anderson wrote:

Folks,
Here are the notes that I took during the CBI build planning meeting.  Others can feel free to post additional information or things covered.  (There were times when I was listening and did not write much.)  At the end are links to the bugs I opened as a result of our

Thanks for this minutes.

Carl - desired CBI build output:
A copy has to happen - this is a post build step - the product is left in product folders w/ funny name - during the copy, SNAPSHOT needs to be renamed to build ID

What do you call "product" ? The output p2 site? If it's just a matter of file names, you could tweak the pom files for the p2 repository to copy or rename the output file. At this point (in Maven build) you should have access to the necessary variables to give it a more descriptive name.

Can we use the current build output as the "committers" output? (Discussion ended with "No, it needs additional tweaking")

What needs necessary tweaks?

We could use a committer id to copy from the Hudson machine to the download area

What about making hudson user one of WTP committers?

If something goes wrong, we don't want to copy any of that output into the repository (to avoid comparator problems)

If Maven build fails, then the job is terminated and following steps (such as copy to download) are skipped. So this requirements seems to be the default Hudson behaviour.

Dependencies - Thanh put variables into the parent pom file to determine the dependencies.  We would need to parse them out.
David - the platform uses target files to specify exact dependencies.
Thanh - the Tycho build generates zip files already (Carl will check to see that it installs directly by unzipping)
Carl - can we set up the CBI build to still complete, even with JUnit problems
Thanh - currently, the build completes, but JUnits are turned off.  With CBI, as soon as it builds, it runs a test.  That's why the build fails if  a JUnit fails- it runs the JUnits as soon as they are built.

For CBI, it's been discussed in a previous mail. Thanh made the necessary changes AFAIK. It's about using -Dmaven.test.failure.ignore=true and -Dmaven.test.error.ignore=true and --fail-at-end.

David - there is a RedHat extension to Maven to allow all of the tests to run outside of (after) the build

Not sure if you're referring to the process we use for JBoss Tools build. but if so, let me describe it to you:
* We use "mvn install -DskipTests" so the binaries get stored in local Maven repo without tests to run
* We publish these artifacts to our "snapshots" area.
* Then we do "cd tests; mvn clean verify" which, in general, will use the stuff that was just mvn install'd to run tests. There is a pitfall to that: https://bugs.eclipse.org/bugs/show_bug.cgi?id=418546

David listed some possible issues to investigate:
Run a Tycho extra bundle- pomupdater - updates the pom with the appropriate version from the MANIFEST, prints out a reminder

IMO, it's better to let the build fail when poms are wrong that sending a reminder. People are generally more reactive to build failures than they are to recommendations.
The issue with pomupdater is that if you rely on it, then you can have things that build on CI because pomupdater fix them, whereas they won't work locally. IMO, CBI should also focus on local builds.

Carl - about Mickael's note- we can set up small builds, but we want all of WTP to build at the same time.  We can have separate builds for smaller projects, but we want to have one build with consistent dependencies.  We currently have a build just for JSDT that runs separate, and can have builds like that, but the output of that is not used in the overall WTP build.

That makes sense.

David - WTP could set up a bunch of small builds that run in serial.  That would still work.

For JBoss Tools, we set up cascading of builds (a build will trigger the one that depends on it) and we also use the buildflow plugin to describe our whole build process: https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin . The drawback is that we don't have a big all-in-one build. However this hasn't seem necessary for us to have this big all-in-one build for the last 2 years or so.
But this may not fit WTP.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets