[Anthill-pro] Branching "best practices"

Thu Sep 25 12:14:00 CDT 2008

If you define the trigger in the repo definition itself it provides you
with that script.

==========
Curtis Yanko
Application & Developer Infrastructure Services
Source->Build->Deploy
W: 860.702.9059
M: 860.881.2050

________________________________

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Peter
Steele
Sent: Thursday, September 25, 2008 1:12 PM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Branching "best practices"

How does Anthill deal with these additional parameters? When I create a
repository trigger the "Address" field has something like

            /trigger?code=48ad8f6be6a2c457190709d537ab315c62a48896

and the associated comments say to "Configure your repository to post to
this url," so that's what I did. I didn't even know about these
additional parameters you've included in your wget call. I've just
checked the docs and see an example talking about the post-commit hook
under Windows, and they use these additional parameters. I take it with
these parameters you can use a single repository hook for all branches?

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Yanko,
Curtis
Sent: Thursday, September 25, 2008 9:41 AM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Branching "best practices"

We use a minor variation on the suggested trigger script which passes
along the directory of the change.

Here is the stack suggested script with one of our 'codes'

#!/bin/bash

TRIGGER_URL="http://ahp.uhc.com/trigger"
REPOS="$1"
REV="$2"
CODE="d3ed3f21eafe187df6b706aed5f84b0e5a111f7b"

DIRS=$(svnlook "dirs-changed" "$REPOS" -r "$REV")
DIRSCHANGED=
REVISION_DATE=$(svnlook "date" "$REPOS" -r "$REV")

for DIR in $DIRS; do
  DIRSCHANGED="$DIR,$DIRSCHANGED"
done

wget --tries 1 --no-check-certificate "$TRIGGER_URL" \

--post-data="code=$CODE&dirs-changed=$DIRSCHANGED&revision-date=$REVISIO
N_DATE" -O /dev/null

==========

Curtis Yanko

Application & Developer Infrastructure Services

Source->Build->Deploy

W: 860.702.9059

M: 860.881.2050

________________________________

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Peter
Steele
Sent: Thursday, September 25, 2008 11:56 AM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Branching "best practices"

We use SVN triggers as well, but unless I'm missing something we're
going to need to create a new repository trigger to control the new
branch. Our svn hook script would look something like this after
updating it to handle the new repository trigger:

cmd = svnlook changed %s -r %s" % (Repository, Revision)

files = os.popen(cmd).read()

if re.search("<svn-path-for-main", files):

    cmd = "/usr/bin/wget -t 2 http://vega:8080/trigger
--post-data='triggerId=24&code=blah blah' 2>&1"

    out = os.popen(cmd).read()

    print "wget output:\n%s\n" % out

elif re.search("<svn-path-for-beta1>", files):

  cmd = "/usr/bin/wget -t 2 http://vega:8080/trigger
--post-data='triggerId=51&code=blah blah blah' 2>&1"

  out = os.popen(cmd).read()

  print >>log, "wget output:\n%s\n" % out

end

We'd add to this each time we'd branch. I take it you have something
different setup?

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Yanko,
Curtis
Sent: Thursday, September 25, 2008 8:22 AM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Branching "best practices"

We just create a WF for each branch that utilizes the same build Job but
is attached to a different part of the repo. We use SVN triggers so once
defined they work for any project in any branch.

==========

Curtis Yanko

Application & Developer Infrastructure Services

Source->Build->Deploy

W: 860.702.9059

M: 860.881.2050

________________________________

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Peter
Steele
Sent: Thursday, September 25, 2008 11:00 AM
To: AnthillPro user and support list.
Subject: [Anthill-pro] Branching "best practices"

We're about to branch for the first time as we near the beta release of
our product. That means we'll be building two separate streams each day
as development continues in the main branch and bug fixes are made in
the beta branch. Are there "best practices" recommended for Anthill as
far as managing branches are concerned? We have a workflow now that we
call "full build" that we run each night to generate our official daily
builds. I had hoped I could somehow parameterize this workflow to
support multiple branches, but now that I know more about Anthill I
don't think that is feasible. From what I can tell we're going to have
to duplicate this workflow to create one for the beta branch, changing
the source repository and other properties accordingly. I guess I'll
rename "full build" to "full build main" and call the beta workflow
"full build beta1". The workflow definition should be identical, and I
assume most people doing branches do not duplicate all of their job
steps for the beta branch.

I'll do the same kind of thing for our CI build workflow, and set up a
new repository trigger for that workflow. 

Is there anything else we need to be prepared to do on the Anthill side
of things?

This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to

which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.

This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to

which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.

This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20080925/7d1e1834/attachment-0001.htm