[Anthill-pro] Anthill3 questions

[Curley, Patrick]

Yes, please send me the draft documentation on notifications when it's
ready thanks.

-----Original Message-----
From: anthill-pro-bounces at caladin.urbancode.com
[mailto:anthill-pro-bounces at caladin.urbancode.com] On Behalf Of Eric
Minick
Sent: Thursday, September 07, 2006 3:54 PM
To: anthill-pro at caladin.urbancode.com
Subject: Re: [Anthill-pro] Anthill3 questions

Patrick,

I've answered your questions in line.

Curley, Patrick wrote:

> 1. In Anthill3 preview-11 I set a property called RELEASE in my 
> workflow.  So now when I do a manual build and I am prompted for the 
> release; all good, how do I access this in my Ant script? 
>
Add a build property to the Ant builder with the format: 
-DRELEASE=${property:RELEASE}

> 2. I want to use this value (RELEASE) on the dependant projects 
> (within their Ant scripts) that this project calls, is this possible? 
> How?
>
Build properties are currently not passed down to dependencies. Would it

be possible to use the same artifacts from previous builds and do some 
post processing on them that uses the value of RELEASE? The generic step

"Run workflow on dependencies" does receive this property and it could 
be used on those dependencies. That could be a good fit, but if post 
processing is involved, it would probably make more sense for the main 
build script to do that work as part of the build.

What do you do with that property in the dependencies?

> 3. We have a license for Anthill 2.5 how do I migrate this to
Anthill3?
>
Right now we are not converting licenses. When the 3.0 release is live 
there will be a section of the website that does it automatically.

> 4. When setting up a dependency, is there a way to force the dependant

> project to build?  What does* Use Latest Build Artifacts* do?  Within 
> the project that is the dependency, I already have the tag option set 
> in the* Source Config**,* so is this tag being used when this project 
> is being called from another project as a dependency?
>
The general assumption is that dependency projects have their own 
lifecycle. They are built on their own under their own rules and Anthill

Pro3 delivers the results of thier builds up to dependent projects. 
Right now, there is not an always build requirement, partially to avoid 
unrelated builds repeatedly kicking eachother off.

So the tagging rules in the dependency will be used whether the 
dependency is built on its own or if it is triggered by a dependent 
projet. When a project builds it is not very aware of the fact that it 
is being built as a dependency. A common use of the 'Run Dependency 
Workflow' generic step is to lookup the original label applied to the 
dependency artifact and add a the dependent's label. So if you have a 
dependency project that is build rarely, the dependent project will 
reuse the same binary over and over again applying labels back to the 
dependency's source code each time. Rebuilding isn't needed.

The Latest Build Artifacts lets you specify some simply rules and take 
the most recent product of a dependency project that meets those 
conditions. So you could create a QA status level and mark dependent 
projects as being passed by QA whenever they are. Then your dependent 
project could decide to just use the most recent artifacts that passed 
QA. Earlier in the development cycle, you will probably just want the 
most recent artifact that built (successful status) and later you might 
want to stick to release level artifacts.



> 5.** My e**mail config must not be setup correctly.  Sometimes no 
> email is sent at all and the log says: **
>
> 2006-09-07 13:11:02-0    WARN  507 0 - No Email Address Found For
build
>
> 2006-09-07 13:11:02-10   WARN  507 0 - No email addresses found for 
> users, skipping email command
>
> This is always successful.
>
> Sometimes** I** get an email with a subject line of:  * Workflow: 
> $project.Name - $workflow.Name 
> ($workflow.BuildLife.LatestStamp.StampValue): $workflow.Status.Name* 
> and a body of* Workflow: $workflow.Name*
>

It looks like you may be using the email publisher. That is not the 
preferred way of sending build status emails. The preferred mechanism is

to configure a notification scheme and select that scheme in the 
workflow configuration. The email 'publisher' is probably going to be 
renamed as 'email integration' and is mostly intended as a way of 
communicating with third party applications that take automated action 
based on emails. It could work for notifications as well, but is less 
appropriate and provides the email template with different set of input 
(resulting in velocity not being able to resolve anything in the example

you provided).

I should have draft documentation on notifications done in the next 24 
hours, drop me a note if you would like a copy of it.

-- Eric

> *** *
>
> Any ideas?
>
> Thanks,
>
> Pat Curley
>
>-----------------------------------------------------------------------
-
>
>_______________________________________________
>Anthill-pro mailing list
>Anthill-pro at lists.urbancode.com
>http://lists.urbancode.com/mailman/listinfo/anthill-pro
>  
>

_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro