+1 for running Junit after successful build-$branch, build-marvin, build-docs, build-apidocs etc. But in my opinion packages should be built even if Junit tests fail as some additional features/check-ins can be testable.
Blocker issues can be logged for Junit failures and pursue them in parallel. For time being it is ok as there are not that many Junit tests and 1 or 2 failures can get fixed pretty fast. When the suite becomes sizable, if there are multiple failures, fixing them may take some time and not having latest build would cause delays in release cycles. -----Original Message----- From: Chip Childers [mailto:[email protected]] Sent: Wednesday, September 12, 2012 1:23 PM To: [email protected] Subject: Re: test lifecycle On Wed, Sep 12, 2012 at 4:16 PM, David Nalley <[email protected]> wrote: > Hi folks, > > I am thinking about making some changes to jenkins and figured I'd > toss it up here before I do it to make sure no one disagrees. > > Here's my frustration: We are getting spammed by lots of jenkins > notices, many needlessly. > > Prime example: junit failures when the build also failed. IMO we > shouldn't even try running the unit tests as there is an explicit > dependency to compile and we 'know' it won't build. > > So I'd run build-$branch on each commit - if successful it would > trigger build-marvin, build-docs, build-apidocs, and junit. If junit > succeeds build packages (though eventually we probably want to > run-marvin first, but for the moment) > > Thoughts, comments, flames? > > --David > Sounds perfect!
