[Anthill-pro] Artifacts delivery and resolve.
Frederic Jean
frederic.jean at ubisoft.com
Thu Mar 13 13:34:17 CST 2008
Ok i see !
Now here is another question :
Let's say I have my workflow A that build a lib with property like platform/target
My workflow B use that lib to build unittest binaries using the same property platform/target
My workflow C use that lib to build stress test binaries using the same property platform/target
Now I set a dependency in workflow B and C to pull a build of workflow A... how do I propagate my properties of workflow B/C (platform/target) to my workflow A ?
Another problem is in my case both workflow B and C will need the use the same workflow A (well same buildlife - not sure if it's the appropriate term) now if both workflow C and B pull a build from workflow A , will the system be aware of it and build workflow A only one time and push artifact to both workflow B and C ?
How its better I use a push build behavior on workflow A to build workflow B and C ?
So far the project I use as a prototype to test Anthill , I need to compile like 8 platforms x 2-4 targets x 4 type of test (unit/stress etc)
On my current build system I had to create like 300 job (real pain) and with anthill , just with the possibility to iterate job in a workflow I have a generic build job that with platform/target I can virtually build any flavor of my library by passing platform/target using iteration for my job in my workflow(great)
Now here is the design I thought to implement for my Daily Build.
Main daily workflow
Job iteration x X (platform/target combinaison)
-> this job call another workflow that build(Workflow A) my lib for the given platform/target then once finished
that workflow trigger a push build to another workflow(B and C) that build the unittest which then each of them call another workflow to execute those test.
Well my question is in my situation and with your experiences, am I on the right track ? is my design too "generic" ? would it be better i split them in a more specific manner like a job per platform or something ?
Sorry guys for all the questions but I'm just looking of what could be the best practices for my kind of project :)
Thank you very much !
-----Message d'origine-----
De : anthill-pro-bounces at lists.urbancode.com [mailto:anthill-pro-bounces at lists.urbancode.com] De la part de Ryan Smith
Envoyé : 13 mars 2008 14:23
À : AnthillPro user and support list.
Objet : Re: [Anthill-pro] Artifacts delivery and resolve.
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
===========================================================
_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro
More information about the Anthill-pro
mailing list