Re: Project requiremodification with, forceOnly

View: New views
2 Messages — Rating Filter:   Alert me  

Re: Project requiremodification with, forceOnly

by Dan Rollo-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Jacob,

Looking this over led me to CC-647
(http://jira.public.thoughtworks.org/browse/CC-647).

I think these are related, and any patches should include documentation
updates too (as is seems how things behave is clear as mud right now...).

I haven't worked through these use cases myself, so I expect my own doco
  updates are much clearer.

If you'd like to create a new Jira issue for this, or just attached
patches to CC-647, I'd be happy to look it over.

Thanks,
Dan



Subject: [Cruisecontrol-user] Project requiremodification with
        forceOnly
To: cruisecontrol-user@...
Message-ID:
        <283639500910071515w7d7adfd7r6799354b0e1a3bd@...>
Content-Type: text/plain; charset=ISO-8859-1

I've noticed some others have encountered the same issue I had, which
was the need to use force only builds with modification being
required. It would seem to me that if it was the intention for
"buildWasForced" (Project.java) to override other configuration
options, that it would be the first option checked rather than the
last.

Given these cases:

CASE 1) I want to schedule builds regardless of changes (none)
CASE 2) I only want to build if something has changed (requiremodification)
CASE 3) I want to build by force once, regardless of changes (none OR
requiremodification)
CASE 4) I only want to build by force, regardless of changes (forceOnly)

the only case that I can think of for using both is:

CASE 5) I only want to build by force and only if there are changes
(forceOnly + requiremodification)

Anyway, the way I fixed my issue was as follows:

Project.java (440) if (buildWasForced) {
changed to
Project.java (440) if (buildWasForced && !(forceOnly &&
requiremodification) ) {

This will continue to respect the rules to force a build if the
project is "forceOnly" or "requiresmodification", including if there
were no changes or neither option is set, while preventing a build
when using both options.

Thanks,
Jacob S

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Cruisecontrol-user mailing list
Cruisecontrol-user@...
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-user

Re: Project requiremodification with, forceOnly

by Jeffrey Fredrick-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hi Dan, I think that CC-647 is way out of date (see my recent comments there). I think you probably need to remove your doc change...

Jacob, I think you make a good case for the intersection of the two attributes.... except for the debugging case: I don't have any modifications but my build is failing and I want to see if I've fixed it.  But in that case you can temporarily change the attribute and change back, so that isn't a big deal.

Feel like submitting the patch? (Please create a new JIRA issue.)

Jtf


On Thu, Oct 8, 2009 at 6:34 PM, Dan Rollo <danrollo@...> wrote:
Hi Jacob,

Looking this over led me to CC-647
(http://jira.public.thoughtworks.org/browse/CC-647).

I think these are related, and any patches should include documentation
updates too (as is seems how things behave is clear as mud right now...).

I haven't worked through these use cases myself, so I expect my own doco
 updates are much clearer.

If you'd like to create a new Jira issue for this, or just attached
patches to CC-647, I'd be happy to look it over.

Thanks,
Dan



Subject: [Cruisecontrol-user] Project requiremodification with
       forceOnly
To: cruisecontrol-user@...
Message-ID:
       <283639500910071515w7d7adfd7r6799354b0e1a3bd@...>
Content-Type: text/plain; charset=ISO-8859-1

I've noticed some others have encountered the same issue I had, which
was the need to use force only builds with modification being
required. It would seem to me that if it was the intention for
"buildWasForced" (Project.java) to override other configuration
options, that it would be the first option checked rather than the
last.

Given these cases:

CASE 1) I want to schedule builds regardless of changes (none)
CASE 2) I only want to build if something has changed (requiremodification)
CASE 3) I want to build by force once, regardless of changes (none OR
requiremodification)
CASE 4) I only want to build by force, regardless of changes (forceOnly)

the only case that I can think of for using both is:

CASE 5) I only want to build by force and only if there are changes
(forceOnly + requiremodification)

Anyway, the way I fixed my issue was as follows:

Project.java (440) if (buildWasForced) {
changed to
Project.java (440) if (buildWasForced && !(forceOnly &&
requiremodification) ) {

This will continue to respect the rules to force a build if the
project is "forceOnly" or "requiresmodification", including if there
were no changes or neither option is set, while preventing a build
when using both options.

Thanks,
Jacob S


--
CITCON
Continuous Integration and Testing Conference
http://www.citconf.com/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Cruisecontrol-user mailing list
Cruisecontrol-user@...
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-user