[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] Ganymede builds broken for 3 nights
|
Hi, sounds like you guys had some fun.
Since we contributed our bits on Wednesday and heard
nothing, we took the weekend off. I did correct the spelling of Development in
the cdt.sc file. I assumed that the data was normalized and that was the only
place where I would see that string, but I guess not. Sorry for causing the
panic. And thanks David for fixing this for us.
Now what the heck is that CPP EPP error I just got from the
auto-blame-parser without us touching anything?
Doug.
> > But, I think you are saying CDT _was_
receiving notices for this
> > case I mentioned, that
> No, CDT was not receiving emails. If it had been,
the status on the
> web page would have said "Failed (cdt)".
Oh, ok ... I misunderstood ... Vivian and Doug you can
ignore my questions. :) > > 1b)
as far as I am concerned, you can notify everyone in the .sc
> > files
when there's a failure! > I chose not to
do that for Ganymede (it may have been a poor
> decision, but hear me
out) because for Europa people were getting
> too many build failure
emails and were ignoring them. So for
> Ganymede, the build failures are
only emailed to the detected
> projects. Anyone who wants to see
the whole stream of failures can
> monitor the "failed build rss
feed". Good point. Option '1' is better
then, if that's feasible to implement.
> > 3) I'd suggest that a build be
done when ever a change is checked in
> > ... instead of once every 24
hours ... this way we can sometimes
> > detect 2, 3, or 4 errors
within a day, instead of having to wait for
> > 2, 3, or 4 days.
> Do you have a script for doing
that? The way we do in in WTP and Orbit is
to use CruiseControl, which "monitors" a CVS module for any changes and invokes
the build if any thing changes. In our projects, that module is our map projects
(not code modules). For Ganymede, that'd be the project with the .sc files in
it. If you have one ant script, or shell script, that I can execute (from a
process with my logon id, that is) then I can try adding it to the Orbit CC
(since it's not all that busy) to test it out (and leave the normal cron job
running, until we know if it works ok). If it seems to work ok, and you want
"control" over the CruiseControl instance, it'd be fairly easy for me to help
you get it set up. I'm sure there are ways of implementing all this without CC,
but ... we use it just because it's all built in, with no new programming, just
a config file written with XML tags (similar to ant).
| From:
| Bjorn Freeman-Benson
<bjorn.freeman-benson@xxxxxxxxxxx>
|
| To:
| Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
|
| Date:
| 02/17/2008 08:21 PM
|
| Subject:
| Re: [cross-project-issues-dev] Ganymede
builds broken for 3 nights |
David M Williams wrote: Ok, Ok, I believe you ... uh, except you _just said_ it didn't always
work. :) No :-) I said "it doesn't always email the
correct project" but I didn't say "it doesn't always work" - when it can't
figure out the project, it emails me. But, I think
you are saying CDT _was_ receiving notices for this case I mentioned,
that No, CDT was not receiving emails. If it had
been, the status on the web page would have said "Failed (cdt)".
1b) as far as I am concerned, you can notify
everyone in the .sc files when there's a failure!
I chose not to do that for Ganymede (it may have been a
poor decision, but hear me out) because for Europa people were getting too many
build failure emails and were ignoring them. So for Ganymede, the build failures
are only emailed to the detected projects. Anyone who wants to see the
whole stream of failures can monitor the "failed build rss feed".
3) I'd suggest that a build be done when ever
a change is checked in ... instead of once every 24 hours ... this way we can
sometimes detect 2, 3, or 4 errors within a day, instead of having to wait for
2, 3, or 4 days. Do you have a script for doing
that?
- Bjorn
--
[end of message]
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
