[Anthill-pro] Artifacts delivery and resolve.

[Ryan Smith]

Frederic,

The most common usage of the "Run Dependency Workflow" is to apply statuses or source labels to the project you use as a dependency.

For example, you have a build of Project A that uses the artifacts from Project B. Now you want to take that build of Project A and run a workflow that marks it as released to production. First it applies a status signifying it is released and then labels the source code. It could also use this step to run a similar workflow on Project B and its other dependencies so they are labeled and given a released status.


Ryan Smith

Frederic Jean wrote:
> Thanks , its more clear now, the only thing that im still confused with 
> is this :
> 
>  
> 
> *The "Run Dependency Workflow" runs a selected workflow 
> (non-originating) on all of a build's dependent projects.  For example, 
> if Project A, depends on Project B and Project C, and you used the Run 
> Dependency Workflow, you may choose to run functional tests, or some 
> list of shell commands on both Project C and Project B's most recent 
> successful builds.*
> 
> * *
> 
> So correct me if im wrong (this refer to my previous e-mail also)
> 
>  
> 
> Let’s say I have  workflow A which build my unittest binaries and 
> deliver them as artifacts.
> 
> And workflow B in the same project that would test those binaries
> 
>  
> 
> Then in my build job of workflow a, I could call *Run Dependency 
> Workflow * on workflow B ?
> 
> I have some difficulty to “picture” this  and see the difference between 
> both option.. ?
> 
>  
> 
> Thank you
> 
> Frederic Jean
> 
>  
> 
> *De :* anthill-pro-bounces at lists.urbancode.com 
> [mailto:anthill-pro-bounces at lists.urbancode.com] *De la part de* Steve Boone
> *Envoyé :* 13 mars 2008 10:43
> *À :* AnthillPro user and support list.
> *Objet :* Re: [Anthill-pro] Artifacts delivery and resolve.
> 
>  
> 
> Frederic,
> 
> The "Run Another Workflow" step, allows you to run start another 
> workflow (non-originating) from the same buildlife.  This step proves to 
> be very handy for many of our customers. 
> 
> For example, you may want to run a deploy workflow, immediately after 
> your build.  One option available is the Run Another Workflow step, that 
> will allow you to select that workflow, and it will cause it be run, 
> after every build.
> 
> The "Run Dependency Workflow" runs a selected workflow (non-originating) 
> on all of a build's dependent projects.  For example, if Project A, 
> depends on Project B and Project C, and you used the Run Dependency 
> Workflow, you may choose to run functional tests, or some list of shell 
> commands on both Project C and Project B's most recent successful builds.
> 
> Now, lets discuss Originating vs. Non-Originating.
> 
> Originating workflows, are workflows that contain jobs that produce 
> Artifacts.  These are usually referred to as Build Workflows. 
> 
> Non-Originating workflows, contain jobs that perform some sort of 
> functionality to the competed Originating Workflow.
> 
> Now, that can be confusing, lets look at an example.
> 
> You have your project, and you would like to it to build.  You would 
> create your Build Job, and place it in an Originating Workflow.  
> Originating workflows, allow you to configure any dependencies that 
> build might have, and it allows you to determine how you will store 
> those aritfacts, and which files should go into which artifact sets.
> 
> Now, once that project is built, what do you want to do with it?  
> Perhaps you want to deploy the artifacts to QA, or PROD?  Maybe you want 
> to run some tests on the artifacts?
> 
> These kinds of procedures are defined in Non-Originating workflows.  
> They do not need to know about the jobs dependencies, or how the 
> artifacts need to be configured, because at this point, they are just 
> recipes for the list of jobs we are running.
> 
> Hopefully this is clear.  If I have confused you, please let me know.
> 
> Cheers,
> Steve Boone
> 
> On 3/12/08, *Frederic Jean* <frederic.jean at ubisoft.com 
> <mailto:frederic.jean at ubisoft.com>> wrote:
> 
> Can someone explain me the difference between these two options in 
> Miscellaneous Steps?
> 
>  
> 
> -Run Another Workflow Run a workflow on this buildlife
> 
> -Run Dependency Worklfows Run a workflow on each of this buildlife's 
> dependencies
> 
>  
> 
> What does the later mean and do you have an example where it could be 
> handful or how to use it ?
> 
>  
> 
>  
> 
> I'm not sure also if I understand the concept of originating VS 
> non-originating workflow. And why a non originating workflow can't have 
> any dependencies at all ?
> 
> Also do you have an example of use of non-origination vs originating 
> workflow ?
> 
>  
> 
> Is there a way to have an alias name for an iterated job ?  
> 
>  
> 
> I have a workflow where i iterate a job and i pass  the target 
> /platform/type of test  as properties. But the only thing I see when I 
> check report is the job name + its iteration number…
> 
>  
> 
>  
> 
>  
> 
> Thank you
> 
>  
> 
> Frederic Jean.
> 
> 
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com <mailto: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

-- 
===========================================================
Ryan Smith.           		2044 Euclid Ave., Suite 600
Developer                   Cleveland, Ohio 44115
Urbancode, Inc.
                                email:  rws at urbancode.com
web:     www.urbancode.com      phone:  216-858-9000
web:     www.anthillpro.com     fax:    216-858-9602
===========================================================