[Anthill-pro] Build Promotion Reference?

[Eric Minick]

I'd only expect a v to get tossed in if your stamp starts with a
digit. A label in CVS has to start with a non-digit character so if
your stamp is illegal we try to make it legal. Leading digits are
prepended with a 'v' as in "version". Illegal characters (like spaces)
are replaced with underscores.

-- Eric

On Thu, Oct 2, 2008 at 8:23 AM,  <Mark_Melvin at amis.com> wrote:
>
> Hi Eric,
>
> Thanks for the tips, however I cannot find the step you are talking about
> for running a workflow on dependencies.  Is this perhaps a new feature that
> is not in the currently available build of 3.5.4?
>
> Also, when trying to get the remote labeling to work I found that AnthillPro
> prefixed my stamp with a 'v' when it labeled my source code (I emailed
> yesterday about it).  Where exactly is the 'v' coming from?  I guess if I
> use a date I don't need to worry about it.  I'll try that next.
>
> Thanks,
> Mark.
> ----------------------------------------------------------
>
>
>
> Eric Minick <etm at urbancode.com>
> Sent by: anthill-pro-bounces at lists.urbancode.com
>
> 10/01/2008 10:51 PM
>
> Please respond to
> "AnthillPro user and support list." <anthill-pro at lists.urbancode.com>
> To
> "AnthillPro user and support list." <anthill-pro at lists.urbancode.com>
> cc
> Subject
> Re: [Anthill-pro] Build Promotion Reference?
>
>
>
>
> Mark,
>
> Both the labeling the labeling of the dependencies are relatively
> straight forward. You'll want a workflow called something like "Mark as
> Milestone" for both A and B. Especially for B, names count and should be
> consistent across dependencies.
>
> For the label, I'd strongly recommend the remote label. I think you have
> two ways of specifying the source, a date or an earlier label. Either
> works. For the date, you can do something like
> ${bsh:WorkspaceDate.get()} - edit a populate workspace step and steal
> whatever is put in there by default. For the stamp, you'll look up the
> stamp by style: ${bsh:StampLookup.getLatestStampValueForStyle("build")}
> (assuming the right stamp style is named 'build').
>
> As for running things on the dependencies, there's a step (I believe
> under Misc) called "Run workflow on dependencies". Give it the name of
> the workflow you'd like to run and it will take care of looking up the
> dependent build lives and running the workflow against them.
>
> Cheers,
>
> Eric
>
> Mark_Melvin at amis.com wrote:
>>
>> Hi There,
>>
>> As part of my AnthillPro setup I am working on a build promotion
>> paradigm.  I totally agree with the general philosophy that the builds
>> should just be performed, and later moved through the various stages
>> of its life using secondary processes.  However, I find there to be
>> little info available on these secondary processes.  I have seen the
>> "Run a Simple Deployment" section in the help - but it is fairly
>> sparse and really only talks about deploying files (not labeling,
>> walking dependencies, etc.).  I think, while a lot of it is
>> company/process-specific, there is also a great deal that is common as
>> well.  I'm interested in learning how other people deal with this, and
>> perhaps even getting ahold of an example workflow/job.  This would be
>> an invaluable resource for someone like me who is new to AnthillPro.
>>
>> Anyway, what I am particularly stuck on is how to deal with
>> dependencies.  For instance, let's say that I have Project A which
>> depends on Project B (to keep things simple).  If Project A is the
>> "thing" that I am shipping, and I have a build of it that I want to
>> promote to some new status, I would like to be able to open a specific
>> build life for Project A and initiate the build promotion process,
>> specifying a status to promote it to (milestone, release, whatever).
>>  This will (roughly):
>>
>>     * Get Project A's artifacts for the selected build life
>>     * Deploy Project A's artifacts somewhere, perhaps even archiving
>>       the BOM
>>     * Change Project A's status to the new status specified by me
>>     * Label the source that went into that particular build life for
>>       Project A using a new "release" stamp style
>>     * Traverse all the build lives for Project A's dependencies (in
>>       this case, Project B) and perform a similar operation
>>
>>
>> It is the last two points that I am stuck on.  First off, would a
>> simple "CVS Label" operation (we use CVS) similar to one that is done
>> as part of a standard originating workflow work for me in this case
>> (i.e. will it look up the version of the source used for the build
>> life I am working on and apply the label to that)?  If not, would I
>> need to use the more complicated "CVS Remote Label", and label the
>> source that was labeled with the old development stamp? I assume I
>> would need a non-trivial script to look up the old stamp from the
>> build I am promoting, and basically use this task to apply the new
>> stamp to the source (presumably via a "cvs rtag" under the covers)
>> using the old stamp as the remote tag.
>>
>> Second, is there any way to have a workflow trigger the same workflow
>> on other projects (the dependencies in this case)?  Let's say for
>> simplicity's sake that all my build promotion workflow does is apply a
>> tag that I specify (RELEASE1_0) to all source involved in the build.
>>  Is there any way I can initiate a promotion on Project A, and have it
>> tag the sources for Project A *and* Project B with RELEASE1_0?  And
>> since this is the same operation, I would like to have one general
>> workflow that is basically called on both projects, but with me only
>> initiating it once at the top-level.
>>
>> If anyone is still following, I would appreciate any pointers or
>> advice one way or another.  My dependency tree is quite large, which
>> is why I'd like to get this fleshed out ahead of time before creating
>> hundreds of projects only to realize I didn't account for something.
>>
>> Thanks in advance,
>> Mark.
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>