# 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
---------------------------------------------------
