Hi
what you can do to get the variables of a previous build is the following,
in the build script, echo out all the needed parameters,
so you can get them back with xsl.
--> in nant <echo message=${CCNetLabel}"/>
so the integration properties of the build will be saved in the build log,
with kind regards
Ruben Willems
On Thu, Jan 22, 2009 at 5:16 PM, CinnamonDonkey <
[email protected]> wrote:
>
> Another problem with being forced to go the separate project route is
> the fact that the many build varaiables that are being passed to and
> from the external tools are no longer in context for the build that
> you where processing. You are in fact now running a different build in
> a different context with different variables.
>
> It would also be impossible to share state information.
>
>
>
>
>
> On 22 Jan, 16:01, CinnamonDonkey <[email protected]>
> wrote:
> > Looking at the build log files, they seem to come in two flavours?
> >
> > Examples:
> >
> > log20090116150101.xml <-- for a failed build
> >
> > and
> >
> > log20090119160011Lbuild.91.xml <-- for a successful build
> >
> > This seems to be, log<YYYYMMDDHHMMSS>.xml and
> > log<YYYYMMDDHHMMSS>LBuild.<revision num>.xml
> >
> > Seeing as I need pretty much all the information within these log
> > files I was hoping that at the end of the build process, as the last
> > entry in the Publisher Block, that I could simply append the whole log
> > file for the current build to the end of a digest.xml file wrapped
> > between <digestEntry> ... log file ... </digestEntry>
> >
> > At what point does the log file get written and closed being correctly
> > terminated with </cruisecontrol> and is there an easy way of getting
> > hold of the log file name and passing it into a <exec/> block?
> >
> > If I can't do this I have to effectively manually recreate the log
> > file (becaue I need pretty much everything in it).
> >
> > Regards,
> > Shaun
> >
> > On 22 Jan, 15:03, CinnamonDonkey <[email protected]>
> > wrote:
> >
> > > That is going to be a really great feature!
> >
> > > But it still does not solve the problem of a very cluttered web dash.
> >
> > > Regards,
> > > Shaun
> >
> > > On 22 Jan, 11:53, Ruben Willems <[email protected]> wrote:
> >
> > > > Hi
> >
> > > > good point,
> > > > about the force build stuff, hopefully the security branch will be
> merged
> > > > soon.
> > > > Than it is possible to define users who may do a force build, or
> something
> > > > else.
> >
> > > > The merge is planned for 'soon', but an exact date is not yet known.
> > > > You can find documentation about this security branch at :
> http://csut017.wordpress.com/category/cruisecontrolnet/security-cruis...
> >
> > > > with kind regards
> > > > Ruben Willems
> >
> > > > On Thu, Jan 22, 2009 at 12:48 PM, CinnamonDonkey <
> >
> > > > [email protected]> wrote:
> >
> > > > > The problem with creating multiple projects is that the CCNET dash
> > > > > gets cluttered with projects design for special conditions but all
> > > > > basically the same project. There is no means of hiding them or
> > > > > preventing the end user from doing a force on these special
> condition
> > > > > projects.
> >
> > > > > Also, you have to explain to the end user what each of these
> projects
> > > > > represent and why they should not be doing a forced build on them.
> > > > > With 30+ programmers that's a lot of information to pass out.
> >
> > > > > Whats more, if like us you have 9 different products, the last
> thing
> > > > > you want is 9 products x N special conditions cluttering up the web
> > > > > dash.
> >
> > > > > For the one particular product I am working on (trying to provide
> my
> > > > > lead with the requested features) we already have:
> >
> > > > > Product-Daily
> > > > > Product-Incremental
> > > > > Product-Incremental.onFailRebuildFromScratch
> >
> > > > > Now we will have additionally:
> >
> > > > > Product-Daily.standardReporting
> > > > > Product-Daily.digestReporting
> > > > > Product-Incremental.standardReporting
> > > > > Product-Incremental.digestReporting
> > > > > Product-Incremental.onFailRebuildFromScratch
> >
> > > > > Can you see how this gets a bit messy? It's much better that the
> end
> > > > > users just see:
> >
> > > > > Product-Daily
> > > > > Product-Incremental
> >
> > > > > Much cleaner and less oppertunity for error (they don't need to
> know
> > > > > about these special hidden conditional builds).
> >
> > > > > RE: Complexity...
> >
> > > > > I see it as optional advanced usage. A powerful feature available
> to
> > > > > the user if they wish to use it.
> >
> > > > > I also see this solution as being easier than having to keep
> writing
> > > > > our own scripts and modifying them to detected different conditions
> > > > > and behave differently.
> >
> > > > > Regards,
> > > > > Shaun
> >
> > > > > On 22 Jan, 11:17, Ruben Willems <[email protected]> wrote:
> > > > > > Hi
> >
> > > > > > point one :
> > > > > > it is easier if you set up 2 ccnet projects,
> > > > > > so these can have their own email configuration.
> >
> > > > > > you can play around with xsl, add if statements so some part of
> the info
> > > > > > will not be rendered at certain conditions, but the same mail is
> sent to
> > > > > > all the users in the subject field.
> > > > > > So if you can find a logic way to exclude team leads to get a
> mail
> > > > > > you could keep 1 ccnet project, with a tweaked xsl file. but this
> makes
> > > > > the
> > > > > > configuration very complex.
> >
> > > > > > point 2 is not possible for the moment,
> >
> > > > > > would that not make ccnet to complex?
> > > > > > why not set up 2 projects?
> > > > > > is there a real benefit of having just 1 ccnet project?
> >
> > > > > > with kind regards
> > > > > > Ruben Willems
> >
> > > > > > On Thu, Jan 22, 2009 at 11:55 AM, CinnamonDonkey <
> >
> > > > > > [email protected]> wrote:
> >
> > > > > > > Thanx for the reply Ruben - it's cleared up a few things for
> me.
> >
> > > > > > > A few more questions (sorry, I never run out of questions ;-) :
> >
> > > > > > > 1. Is it possible to apply different email rules based on the
> trigger
> > > > > > > name? We want the Team leads to only receive the digest report
> once a
> > > > > > > week whilst everyone else recieve daily reports IF the build
> fails
> > > > > > > (but not the lead).
> >
> > > > > > > 2. I'm not sure if this is already possible,... erm, it could
> be a
> > > > > > > feature request, example:
> >
> > > > > > > ...
> >
> > > > > > > <triggers>
> > > > > > > <scheduleTrigger time='20:00'
> > > > > > > buildCondition='ForceBuild'
> > > > > > > name="standardReporting" >
> > > > > > > <weekDays>
> > > > > > >
> <weekDay>Monday</weekDay>
> > > > > > >
> <weekDay>Tuesday</weekDay>
> > > > > > >
> <weekDay>Wednesday</weekDay>
> > > > > > >
> <weekDay>Thursday</weekDay>
> > > > > > > </weekDays>
> > > > > > > </scheduleTrigger>
> >
> > > > > > > <scheduleTrigger time='20:00'
> > > > > > > buildCondition='ForceBuild'
> > > > > > > name="digestReporting" >
> > > > > > > <weekDays>
> > > > > > >
> <weekDay>Friday</weekDay>
> > > > > > > </weekDays>
> > > > > > > </scheduleTrigger>
> > > > > > > </triggers>
> >
> > > > > > > ...
> >
> > > > > > > <tasks>
> > > > > > > <standardReporting>
> > > > > > > <exec>
> > > > > > > ... Tasks that only occur for
> triggers
> > > > > > > where name = standardReporting
> > > > > > > </exec>
> > > > > > > </standardReporting>
> >
> > > > > > > <digestReporting>
> > > > > > > <exec>
> > > > > > > ... Tasks that only occur for
> triggers
> > > > > > > where name = digestReporting
> > > > > > > </exec>
> > > > > > > </digestReporting>
> > > > > > > </tasks>
> >
> > > > > > > ...
> >
> > > > > > > <publishers>
> > > > > > > <standardReporting>
> > > > > > > ... Tasks that only occur for
> triggers
> > > > > > > where name = standardReporting
> > > > > > > </standardReporting>
> >
> > > > > > > <digestReporting>
> > > > > > > ... Tasks that only occur for
> triggers
> > > > > > > where name = digestReporting
> > > > > > > </digestReporting>
> > > > > > > <publishers>
> >
> > > > > > > Hopefully an example speaks better than a 1000 words ;-), the
> idea is
> > > > > > > that the trigger name can be used to create sections within the
> task
> > > > > > > blocks that can partition behaviour based on the trigger that
> fires.
> > > > > > > Anything outside these sections will run a normal.
> >
> > > > > > > Is this possible?
> >
> > > > > > > Shaun
> >
> > > > > > > On 21 Jan, 15:36, Ruben Willems <[email protected]>
> wrote:
> > > > > > > > Hi
> >
> > > > > > > > why would you need to make a new email publisher?
> >
> > > > > > > > as far as I know the story, you have a project for daily
> digests,
> > > > > and a
> > > > > > > > project for weekly digests
> > > > > > > > (or 1 project in which you differentiate via the triggername)
> >
> > > > > > > > anyway, the daily reports make an xml file
> > > > > > > > <dailyreports>
> > > > > > > > <fancy data/>
> > > > > > > > </dailyreports>
> >
> > > > > > > > which get merged via the file merge publisher
> >
> > > > > > > > and the weekly reports make another xml file with this layout
> > > > > > > > <weekreports>
> > > > > > > > <fancy data/>
> > > > > > > > </weekreports>
> > > > > > > > which also get merged
> >
> > > > > > > > now in the email publisher,
> > > > > > > > you use 2 xsl files
> > > > > > > > dailyreports.xsl
> > > > > > > > weeklyreports.xsl
> >
> > > > > > > > These are the same as the ones in the dashboard, so you have
> them
> > > > > already
> >
> > > > > > > > normally a 'build' only contains or daily, or weekly data,
> but should
> > > > > it
> > > > > > > > contain both
> > > > > > > > both data will be visible in the mail
> >
> > > > > > > > problem solved ;-)
> >
> > > > > > > > with kind regards
> > > > > > > > Ruben Willems
> >
> > > > > > > > with kind regards
> > > > > > > > Ruben Willems
> >
> > > > > > > > On Wed, Jan 21, 2009 at 4:25 PM, CinnamonDonkey <
> >
> > > > > > > > [email protected]> wrote:
> >
> > > > > > > > > It would be really
> >
> > ...
> >
> > read more ยป
