Hi Marica!
I like the idea, though I think it could be a bit simpler. I'm a bit
unsure why it's coupled to the state and build results at all? Do we
need to track these for historical purposes?
I think at the moment we already have the error state, which AFAICT
are always the result of configuration or transient errors. Perhaps we
could replace that with this?
The types of things I want to see it achieve are:
- same notification mechanism as the rest, but ability to separate
handling (which we have with error types already)
- if it is corrected, it is as if it never happened - ie, no build
result, no notification if it wouldn't have if it hadn't have happened
(eg SUCCESS -> SVN FAIL -> SUCCESS should just report the SVN failure
needs fixing)
- make it possible for Continuum to know it needs to try something
again.
I hope this makes sense... basically I think we should separate the
configuration/pre-build from the actual build.
I'm still not sure if POM errors are really transient :)
Thanks,
Brett
On 30/07/2008, at 12:06 PM, Marica Tan wrote:
Hi All,
I would like to work on the transient state.
Here's what I'm proposing to do:
1. Add two new states: SVN_FAILURE and BAD_POM
* thought of adding just one state: TRANSIENT_ERROR but it's not
descriptive
2. When an error occur due to svn failure or bad pom configuration
then
a. create a build result and set the state to #1
b. retain the old state and latestBuildId of the project ( before
building / updating )
3. Add a new status icon for transient errors. ( No idea yet how it
will
look like. Any suggestions? )
4. In the ProjectGroupAction#summary class:
a. check if there is a build result having SVN_FAILURE or BAD_POM
state
b. if exists, put it in the session for 5 mins and delete the build
result from the database.
c. if not, check if it's still in the session
d. set project state = build result state
e. display the state and associated error message
WDYT?
Thanks,
Marica
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
