|
From: <ste...@Th...> - 2005-09-28 16:26:26
|
Owen (et al),
Here is the first draft of the UrlTrigger stuff talked about last week.
This is the original version that doesn't implement any of the
modificationDelay discussions that were talked about (this can be added
once we have things sorted).
The first 2 files are HttpWrapper.cs and HttpWrapperStatus.cs. These
belongs in project\core\util
The next file is the unit tests for the HttpWrapper. This belongs in
projects\core\UnitTests\Core\Util
The next file is the trigger itself, UrlTrigger.cs and this belongs in
project\core\Triggers
The final file is the trigger unit test file and this belongs in
project\core\UnitTests\Core\Triggers
What I'm really looking for at the moment is any comments on what I've
done. I need to do some testing with this version before we finally
commmit things.
Here is a bit of documentation I had previously on this. It will need
some work though ( I need to dig up the svn scripts we have as well ).
------------------------------------------------------------------------
---------------------------------------------------------
You need to edit you CVSROOT/loginfo file to get the post commit action
to work. On one of our projects we have the following:
----------------------------------------------------------
ALL /usr/bin/cvs-ccnet-notify allmodules
^MODULENAME\(/\|$\) /usr/bin/cvs-ccnet-notify MODULENAME
----------------------------------------------------------
Which basically means for any modules that change update run the
cvs-ccnet-notify script telling it to update the file allmodules. The
second line allows you to be a bit more granular by checking for
specific modules.
The final part is the cvs-ccnet-notify script which is:
---------------------------
#!/bin/sh
cat > /wwwroot/scm/$1
chmod a+rw /wwwroot/scm/$1
---------------------------
The path you need to set to be a folder somewhere on you webserver.
What should happen is that the filename passed as the parameter to the
script ends up containing the contents of the commit log message. You
will obviously need to sort out the proper permissions for the web
folder.
To use the trigger you need the following in your ccnet.config file:
<triggers>
<urlTrigger seconds=3D"60" buildCondition=3D"IfModificationExists"
url=3D"http://hostname/scm/modulename" />
</triggers>
And that should be it.
Things to remember / check:
1) You can manually check that the post commit scripts are running by
checking that the file is being updated on the webserver (one of the
advantages of pushing the log message into the file).
2) When CCNET starts up it should print the URL being used.=20
3) Everytime it checks the URL you should get a message saying that URL
Trigger is checking the following URL. If the URL changes it should
then move onto a checking modifications and query CVS.
4) On first startup it will always check CVS as it doesn't have any
history on the URL so treats it as a change.
------------------------------------------------------------------------
---------------------------------------------------------
Steve
|
|
From: Owen R. <exo...@gm...> - 2005-09-28 20:41:21
|
hi steve, On 28/09/05, ste...@th... <ste...@th...> wrote: > Here is the first draft of the UrlTrigger stuff talked about last week. thanks for the patch! i haven't had the chance to look at it yet, but i hope to get to it tomorrow. i've created a new issue on jira to track this issue: http://jira.public.thoughtworks.org/browse/CCNET-566 cheers, owen. -- Owen Rogers | http://dotnetjunkies.com/weblog/exortech | CruiseControl.NET - http://ccnet.thoughtworks.com |
|
From: Owen R. <exo...@gm...> - 2005-09-29 20:05:54
|
hi steve, i've started to go through the code and it looks good. i have a few questions/comments if you don't mind. httpwrapper: - i tried running the unit tests for the httpwrapper and one of them failed due to a timeout issue. i'm also really concerned about how long the tests take to run. it will also be a source of annoyance trying to run the ccnet unit tests if i'm disconnected and these tests keep failing. so, IHMO, i think that it is ok not to test the httpwrapper *so long as* it is really only a thin wrapper around the httprequest/response objects. however, to get there, i think that it might be important to move some of the logic back into the url trigger. what do you think? - do the httprequest and httpresponse variables need to be members on the class? they are only used within the scope of the Execute method and they are not reused across calls. also, if we make them into local variables, then you don't have to worry about making the class implement IDisposable. - i'm not super comfortable with the httpwrapper class logging and swallowing exceptions. i would also rather have that decision reside in the trigger where it can be more easily testable. what if the httpwrapper simply returned a HttpWebResponse or a wrapper around it?=20 this keeps the httpwrapper very generic and moves the last modified header logic into the trigger where it belongs. urltrigger: - i've taken the liberty of converting the properties into public fields. i know it's more of a philosophical argument, but i've gotten in the habit of converting simple properties into fields as it really reduces the amount of code and improves readibility. i can always go and transparently convert the field into a property at some point later if i need it. - the CheckUrlForChange method seems to be both validating the url and executing the http request. it seems to me that we could integrate the url validating into the setter for the Url property. as far as i can tell, this is the only point that the property is modified. this provides the advantage of alerting the user that the url is invalid right as the server starts up, instead of at the point where the trigger fires. please let me know your thoughts on these suggested changes. cheers, owen. -- Owen Rogers | http://dotnetjunkies.com/weblog/exortech | CruiseControl.NET - http://ccnet.thoughtworks.com |
|
From: Owen R. <exo...@gm...> - 2005-09-30 01:10:32
|
hi steve, i have a few more questions: - the urltrigger seems to return true indicating that the url has changed and that an integration should occur if there was some exception connecting to the url. is this really what we want to do? - in the httpwrapper, in the Execute method we iterate over the http headers to check for the existence of the "Last-Modified" header.=20 however, regardless of whether it exists or not we still return HttpWrapperStatus.ContentReturned which will cause an integration to be triggered. maybe we don't need to worry too much about this as the request.IfModifiedSince will cause an exception if the uri hasn't been modified. still, i'm finding it a bit confusing. - do we need to use request.IfModifiedSince? i personally don't like the fact that it throws an exception if the uri has not been modified since the specified time. could we just check the last modified header instead to see if the uri has been modified? cheers, owen. -- Owen Rogers | http://dotnetjunkies.com/weblog/exortech | CruiseControl.NET - http://ccnet.thoughtworks.com |