[Anthill-pro] Cascading properties

Mon Oct 19 11:47:12 CDT 2009

When you built your "Build From Label" top level project, it would create
all the dependencies with the same label. I was assuming that those probably
wouldn't exist in advance. If they do, then you probably don't need to pull
anything.
To make the pull optional, you can check "cascade force" and leave the force
checkbox checked if you want to build everything, and uncheck it to just
build the top level.

To get much more sophisticated than that, you're probably leaving the
dependency system and doing some of your own scripting somehow.

- Eric

On Mon, Oct 19, 2009 at 10:41 AM, emerson cargnin <
echofloripa.yell at gmail.com> wrote:

> Hummm, that means that it will create several new build lives with the same
> properties? Not sure if that would help much. What would be the other
> options to make it be smarter?
>
> Emerson
>
> 2009/10/19 Eric Minick <etm at urbancode.com>
>
>> Right, that's what I would expect from a pull build with nothing checked.
>> I think you need to force the pull build to force a new build with the label
>> you want.
>> It isn't quite smart enough to check for a matching stamp and build if
>> there isn't one that matches.
>>
>> -- Eric
>>
>>
>> On Mon, Oct 19, 2009 at 9:24 AM, emerson cargnin <
>> echofloripa.yell at gmail.com> wrote:
>>
>>> I used status success and stamp equals the stamp script (that takes in
>>> account the property). If the build life already exists it works fine, but
>>> if not I get:
>>>
>>> Mon Oct 19 16:21:16 BST 2009: Dependent Request (1785255) for Common
>>> resources - Front-end - fetches resources from a label not needed
>>>  Unable to find a existing build life that meets the criteria for Common
>>> resources - Front-end - fetches resources from a label
>>>
>>>
>>> My dependency trigger has pull buildm with nothing checked.
>>>
>>>
>>> 2009/10/19 Eric Minick <etm at urbancode.com>
>>>
>>> Emerson,
>>>>
>>>> Cascading has been available since 3.6.2 I think. New in 3.7.0 was the
>>>> option to turn it off again.
>>>>
>>>> But yes, I've used exactly this strategy to build a whole dependency
>>>> tree from the same label. As long as each workflow is configured to use the
>>>> "labelToBuildFrom" property, you'll be in good position when that property
>>>> is passed along the dependency request chain. And yes, the "With Stamp"
>>>> field accepts properties.
>>>>
>>>> -- Eric
>>>>
>>>>
>>>> On Mon, Oct 19, 2009 at 4:47 AM, emerson cargnin <
>>>> echofloripa.yell at gmail.com> wrote:
>>>>
>>>>> Is the cascading properties feature generally available on the 3.7.1
>>>>> version?
>>>>> Could you please tell me if the following use-case if possible?
>>>>>
>>>>> - I have a build from the label workflow, I wanted the labelToBuildFrom
>>>>> property to be cascaded to the dependency, which is set to be a "pull build"
>>>>> dependency.
>>>>> - It would pull the dependency build life which would have the
>>>>> "build-${property:labelToBuildFrom}" stamp. So that it should create only
>>>>> one dependency per release, which would be shared by several projects. Is it
>>>>> possible to use a property on the "With Stamp" field?
>>>>>
>>>>> Thanks
>>>>> emerson
>>>>>
>>>>> 2009/9/14 Eric Minick <etm at urbancode.com>
>>>>>
>>>>> Triggers holding property values of that type are a bug. It's one that
>>>>>> is fixed in both active development lines and will be addressed in all
>>>>>> future releases (3.7.0 and 3.6.3). And to answer the next question, both
>>>>>> those releases are prepared and awaiting our updated support website before
>>>>>> general availability.
>>>>>>
>>>>>> -- Eric
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 10, 2009 at 9:05 AM, Burney, Hondo <hburney at hoovers.com>wrote:
>>>>>>
>>>>>>> Here is some information we have gleaned. We got bit by the cascading
>>>>>>> property "feature" as well, though we use push dependencies. The
>>>>>>> properties can be inherited from the trigger, and the trigger is
>>>>>>> stored
>>>>>>> as CDATA and not updated when the properties on the workflow are.
>>>>>>> This
>>>>>>> means that on
>>>>>>>
>>>>>>>
>>>>>>> Monday you create a workflow property foo="hello world"
>>>>>>> Tuesday you create a repository trigger
>>>>>>> Wednesday you set the workflow property foo ="goodbye world"
>>>>>>>
>>>>>>> On Thursday when the repository trigger is fired, it sets foo =
>>>>>>> "hello
>>>>>>> world". Frustrating.
>>>>>>>
>>>>>>> This isn't so much a feature of cascading properties but a bug. It's
>>>>>>> not
>>>>>>> obvious and it took us a while to figure it out.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: anthill-pro-bounces at lists.urbancode.com
>>>>>>> [mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of
>>>>>>> Heather
>>>>>>> Wells
>>>>>>> Sent: Wednesday, September 02, 2009 6:36 PM
>>>>>>> To: anthill-pro at lists.urbancode.com
>>>>>>> Subject: [Anthill-pro] Cascading properties
>>>>>>>
>>>>>>> Somehow I only just noticed that 3.6 includes "Cascading Properties,"
>>>>>>> which is a great feature to have, but I haven't found any
>>>>>>> documentation on how these work.  It appears that any pull dependency
>>>>>>> set to "Always Force" will propagate all properties to the
>>>>>>> dependency.  The problem is that my workflows all use the same
>>>>>>> property names, but I don't want ALL of the properties to propagate
>>>>>>> from the dependent workflow.
>>>>>>>
>>>>>>> I'm guessing that I didn't run into this before because I used push
>>>>>>> dependencies, but all my new workflows use pull dependencies and the
>>>>>>> hard-coded Maven properties (like artifactid and versionid, which are
>>>>>>> now all getting overridden by the dependent workflow's value).
>>>>>>>
>>>>>>> How does this feature works?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Heather
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20091019/88a091a3/attachment.htm