[Anthill-pro] Build dependencies and dynamic stamp values

Wed Jul 22 13:09:21 CDT 2009

Hi Eric,

I guess my biggest issue with the 'status' approach is the sheer
overhead in implementing it.  As far as I can see, if I have 10
miscellaneous projects that I want to collect items from and use in my
deployment I will need to:

1) Create a new secondary workflow on all 10 projects to allow me to
assign the new status to the build life.
2) Go out and find the specific build lives of the specific versions of
these 10 projects I want to deploy.
3) For each of these specific build lives, manually run the new
secondary workflow to promote them to the new status.
4) Manually run the deployment, pulling the newly transitioned items as
dependencies and deploying them.

Whereas for the simple form-based approach:

1) Go out and find the specific build lives of the specific versions of
these 10 projects I want to deploy and write down the build life or
stamp value.
2) Manually run my deployment, keying in the 10 stamp values (or build
life numbers) to be used as dependencies.

Unless I am missing something, I get the same traceability through the
dependency links between projects but avoid creating 10 new workflows
(and manually running them) if I go with option b.  Sorry to harp on
this, but I want to make sure I understand it fully.

Mark.

________________________________

	From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Eric
Minick
	Sent: July 22, 2009 11:20 AM
	To: AnthillPro user and support list.
	Subject: Re: [Anthill-pro] Build dependencies and dynamic stamp
values

	Mark,

	In case, the fact that this new status will end up at the bottom
of the status list is a con for you, in 3.7 you'll be able to reorder
the statuses from the lifecycle configuration screen. 

	-- Eric

	On Wed, Jul 22, 2009 at 8:13 AM, Mark Melvin
<Mark.Melvin at onsemi.com> wrote:

		Hi Eric,

		Thanks for taking the time to respond.  I think I am
going to look at the pros and cons of the status approach versus just
providing the stamp values on the submission form to see which one fits
better (and maintains traceability).  Traceability is important, and I
don't want to be hacking the dependency configurations as part of a
build script.

		Thanks,
		Mark.

________________________________

			From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Eric
Minick
			Sent: July 21, 2009 6:28 PM
			To: AnthillPro user and support list.
			Subject: Re: [Anthill-pro] Build dependencies
and dynamic stamp values

			Mark,

			You're bumping into traceability centric rules.
The source code dates, and every build life of dependencies should be
fixed at the moment the workflow starts.

			You've been vague about exactly what this
workflow is for (I assume you need to be) but I'll throw out some ideas.

			The most Anthilly way of doing this would be to
go for the status based approach. Whatever mechanism you'd use to update
the properties file, turn towards promoting these artifacts. If you're
creating a release bundle or escrow package, statuses like, "Approved
for Release" or "Ready for Escrow" would be appropriate and make it
relatively easy to determine the changes since the last time you sent
one of these artifacts out, etc. It sounds like you view that additional
information as noise, which is a little surprising but I can imagine
would be true. 

			If you really, really wanted to use that CVS
file, you'd set up a side project that first grabbed that property file,
then used the API to configure the target project's dependencies, then
ran the build of the target project. That's doable, but can start
stretching the tool in somewhat uncomfortable ways as we go through
upgrades, etc.

			Adding the stamp values to the submission form
would be a great idea if there were two dependencies and a pretty crummy
one if there were 50. That said, if this is something that you only do
twice a year, how slick does it need to be?

			-- Eric

			On Tue, Jul 21, 2009 at 2:47 PM, Mark Melvin
<Mark.Melvin at onsemi.com> wrote:

				Hi Everyone,

				I tend to use properties a lot to make
my builds more generic and
				portable across projects.  I am trying
to accomplish something but am
				currently being thwarted by Anthill and
I could use some suggestions.

				Basically, what I would like to do is
build something *occasionally*
				that depends on a specific revision of
certain artifacts.  So, every
				time I do a major release (say, twice a
year) I want to rebuild a set of
				images from a group of artifacts kind of
half-way down my dependency
				chain (that are not necessarily the
latest, built version).  Let's say I
				have a project ALPHA that depends on
DEP1 and DEP2.  Intially, I want my
				project ALPHA to build using
dependencies stamped as "DEP1_VER1" and
				"DEP2_VER1" (which may not be the latest
versions in Anthill).  Six
				months from now, I want to rebuild ALPHA
with dependencies stamped as
				"DEP1_VER23" and "DEP2_VER23" (which
again may not be the latest
				versions in Anthill).  But I do not want
to go into the project setup
				for ALPHA and change the stamp criteria
for the dependencies.
				I found that in my project setup for
ALPHA, I can define my dependencies
				with a build life status criteria of
"success" and stamp criteria of
				"${property:dep1.stamp.value}" (and
"${property:dep2.stamp.value}").  I
				tested this with dummy properties on the
project and it seems to resolve
				and work just fine.

				Now, I initially thought I could make
the value of these properties
				dynamic and supply the value of
"dep1.stamp.value" and
				"dep2.stamp.value" in a properties file
in CVS as I have a mechanism of
				importing properties from a file and
setting them on the project at
				build time.  But this falls apart
because Anthill seems to need the
				stamp values for the dependencies at the
time the build request is
				triggered, *before* a workflow is even
created, and thus before it
				fetches anything from CVS.  This is
confusing because I have specified
				my dependency trigger to be "None".  Why
does Anthill care about whether
				a dependency build life is present if
there is no trigger?  I thought it
				would wait until the job step was run to
fetch the dependencies (which
				is well after the code is checked out of
CVS and my properties are
				imported and available).

				The only other way I can see to
implement this would be to have a
				special status made up for these
dependencies, and "promote" them to
				that status whenever I want to rebuild
ALPHA.  However, this becomes a
				pain because I have more than just two
dependencies that will need to be
				in this new status and I don't want to
have to manually promote each one
				(it would be very tedious).  And
creating a new status will snowball
				into more configuration on the cleanup
policy page, additional noise in
				the search pages, etc.  It *feels* like
I should be using the status
				mechanism, but what do I do about
promoting all of my dependencies to
				this new status?  Can I create an
operational job to wrap this all into
				one step?  I guess I'd need a job that
allowed me to enter a specific
				stamp for every dependency and promote
those build lives to the new
				status.

				Other options I can see that might work:

				1) I could prompt for the stamp value of
every dependency when the build
				is triggered, but that would be a heck
of a form to fill out when the
				build is triggered.

				2) Ignore the automatic dependency
fetching mechanisms in Anthill and
				fetch my own dependencies from
Codestation as part of the build using
				the Codestation command line client or
Ant targets (icky-icky).

				Can anyone see a way of accomplishing
what I want?  What is the proper
				"Anthill-way" to do something like this?

				I am using v3.6.2_32922.

				Any advice would be appreciated,
				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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20090722/43d02063/attachment.htm