Re: [continuum build trunk - FAILED - update] Wed Aug 15 03:00:01 GMT 2007
M2_HOME was changed in ci_continuum.sh but it wasn't in .profile. I'm changing it and will see if it's better Emmanuel Brett Porter a écrit : is this just a bad env on the zone? might be a hint that the release stuff could have a problem with certain environments too - worth checking. On 15/08/2007, at 3:05 AM, [EMAIL PROTECTED] wrote: Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20070815.030002.txt
Re: [vote] Release Continuum 1.1-beta-2
+1 I gave it the basic run through - added a project, some profiles, checked the licenses. All is well. Very nice work everyone that's done stuff. It's starting to shape up well! - Brett On 15/08/2007, at 12:56 AM, Emmanuel Venisse wrote: Hi, Continuum 1.1-beta-2 is ready for release The highlights are - lot of bug fixes - Installations/profiles screens improvement - screen flow improvement in Add Project part - cancellable builds The Release Notes is available there: http://jira.codehaus.org/ secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13606 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1- beta-2/org/apache/maven/continuum/continuum-plexus-runtime/1.1- beta-2/continuum-plexus-runtime-1.1-beta-2-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1- beta-2/org/apache/maven/continuum/continuum-webapp/1.1-beta-2/ continuum-webapp-1.1-beta-2.war - data management cli: http://people.apache.org/builds/maven/ continuum/1.1-beta-2/org/apache/maven/continuum/data-management-cli/ 1.1-beta-2/data-management-cli-1.1-beta-2-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Re: Solving the notification problem
Files as 1389 and 1390, with some additional comments about the alwaysSend bit. On 11/08/2007, at 2:59 AM, Emmanuel Venisse wrote: Yes they are improvments requests to file. I'm not sure about 2) because we already have the alwaysSend parameter that can be set I won't look at it for 1.1-beta-2 but I'll try for 1.1-beta-3 Emmanuel Brett Porter a écrit : Did I understand the summary to be the following to improvement requests to file? 1) for group notifiers, don't send a mail if another build is scheduled in the group already (instead, have the results added to the mail for that group). Make this a configurable option, on the group notifier itself. Default is off for consistency with current behaviour. 2) add a threshold of messages, particularly for errors - don't send a message that is identical to one sent in the last X hours. Cheers, Brett On 02/08/2007, at 6:26 PM, Emmanuel Venisse wrote: Brett Porter a écrit : On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote: For a project notifier, I think we can keep what we have actually, but for a group notifier, we can send a single mail by project group. The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't need to modify the db schema for this new feature. Sounds good to me. That and eliminating the error condition would be great. I'd like to keep the usage we have actually, so we can use a new parameter in the continuum conf where admin will choose if mail are sent one by one or by project group. Do you think this is a continuum conf, or a group notifier conf? It can be a group notifier conf (it will be better than a global continuum conf) because we don't have specific fields in db for notifier config so we can add what we want. If we do that, what will be the default? Will we allow to set the default in the global conf? Emmanuel
Re: Solving the notification problem
Thanks. Emmanuel Brett Porter a écrit : Files as 1389 and 1390, with some additional comments about the alwaysSend bit. On 11/08/2007, at 2:59 AM, Emmanuel Venisse wrote: Yes they are improvments requests to file. I'm not sure about 2) because we already have the alwaysSend parameter that can be set I won't look at it for 1.1-beta-2 but I'll try for 1.1-beta-3 Emmanuel Brett Porter a écrit : Did I understand the summary to be the following to improvement requests to file? 1) for group notifiers, don't send a mail if another build is scheduled in the group already (instead, have the results added to the mail for that group). Make this a configurable option, on the group notifier itself. Default is off for consistency with current behaviour. 2) add a threshold of messages, particularly for errors - don't send a message that is identical to one sent in the last X hours. Cheers, Brett On 02/08/2007, at 6:26 PM, Emmanuel Venisse wrote: Brett Porter a écrit : On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote: For a project notifier, I think we can keep what we have actually, but for a group notifier, we can send a single mail by project group. The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't need to modify the db schema for this new feature. Sounds good to me. That and eliminating the error condition would be great. I'd like to keep the usage we have actually, so we can use a new parameter in the continuum conf where admin will choose if mail are sent one by one or by project group. Do you think this is a continuum conf, or a group notifier conf? It can be a group notifier conf (it will be better than a global continuum conf) because we don't have specific fields in db for notifier config so we can add what we want. If we do that, what will be the default? Will we allow to set the default in the global conf? Emmanuel
error states
I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
Re: error states
I'm also seeing where there is a real error, like the SVN server not being reachable, and it not trying to build ever again. On 16/08/2007, at 1:40 PM, Brett Porter wrote: I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
