Re: starter/qa/release automation

# from Adam Kennedy
# on Saturday 01 March 2008 02:26:

>section is so simplistic (the
>.test ones make sense, but who's to say that your
>"check_version_control" action is in any way similar to how I want it
> done.

So, you want this to be 'vcs', with a 'type' key, and what else?  
The 'check_version_control' action is just "make sure it is checked-in 
and up-to-date" -- how do you want that done?

svn:
  repository: "file:///tmp/cpdktester/"
  layout:
    trunk: "#DIST#/trunk/"
    tags: "#DIST#/tags/"
    branches: "#DIST#/branches/"
  tag:
    name: "#VERSION#"
    message: "tagging #DIST# release #VERSION#"


>If you compared what you have to my process, I don't see that I could
>make the way I want the process to happen to match your config file
> format.

From your description, it sounds like you want to just delete 
the 'check_kwalitee' step in 'process' and the 'pause_http_relay' step 
in 'shipit', but you want an 'svn_relay' step instead of 'scp_relay'.

So, assuming an svn relay plugin:

  upload:
    svn:
      host: "svnserver"
      dir: "svn/#DIST#/releases/"
    url_base: "http://example.com/svn/#DIST#"

I suppose you would replace the 'pause_http_relay' step 
with 'print_relay_url'.

>That plugin tells the system that it needs to run a check at phase 4, 
>and another check at phase 7, and provides a callbacks for those tests.

I don't want plugins determining the sequence of operations.  They have 
to define actions, which must be listed in the config.  Each step is 
essentially a 'check', though sometimes we only want the side effect -- 
but failure (die) at any step means we stop.

--Eric
-- 
"It is a mistake to allow any mechanical object to realize that you are 
in a hurry."
--Ralph's Observation
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------