2009-06-23 14 views
5

Ich möchte einzurichten Ccnet zu:CruiseControl.NET E-Mail-Verlag Problem

  1. Mail an Committer senden nach jedem Build (unabhängig vom Status)
  2. Mail senden an alle anderen Entwickler, wenn die Build-Pausen oder ist fest

der E-Mail-Verlag Refactoring wird (und angeblich verbessert) Mit jeder neuen Version von CCNet, aber ich habe immer noch das gleiche Problem: nur die Committer benachrichtigt, - wenn die Build-Pausen, andere Entwickler nicht Holen Sie sich die E-Mail-Nachricht. Entweder bekomme ich das System nicht oder es gibt einen lange nicht behobenen Fehler im E-Mail-Publisher.

Ich benutze die v1.4.4.83. Mein Beispiel-Konfiguration (ich die irrelevanten Sachen entfernt):

<email 
    includeDetails="true"> 
    <users> 
     <user name="user1" address="[email protected]" group="developers" /> 
     <user name="user2" address="[email protected]" group="developers" /> 
    </users> 
    <groups> 
      <group name="developers"> 
       <notifications> 
        <notificationType>Failed</notificationType> 
        <notificationType>Fixed</notificationType> 
       </notifications> 
      </group> 
    </groups> 
    <modifierNotificationTypes> 
     <NotificationType>Always</NotificationType> 
    </modifierNotificationTypes> 
</email>    
+0

Dies sieht aus wie eine Funktion, die niemand zuvor benötigte, könnten Sie es bitte auf http://jira.public.thoughtworks.org/browse/CCNET posten? – skolima

+0

Die lustige Sache ist - das war eigentlich in früheren Versionen von CCNet möglich (1.3 von dem, woran ich mich erinnern kann). –

Antwort

3

Ich glaube, dass dies das tut, was Sie wollen (zugegeben, ein Jahr nach Ihrer Frage).

Hinweis: Wir verwenden SVN, mit einem <svn> Block. In CC.NET 1.4.xx unterstützen <email> Blöcke reguläre Ausdrücke, um E-Mail-Adressen aus SVN-Benutzernamen zu ermitteln. Es sollte mit anderen Quellsteuerblöcken funktionieren, aber ich habe nichts außer SVN verwendet.

Wir haben so etwas wie die folgenden in unserem <publishers> Block (Ich habe es geändert Ihre spec passen):

<email ... includeDetails="true"> 
    <!-- Developers get an email whenever the build status changes --> 
    <users> 
    <user name="Dev1" group="developer" address="[email protected]" /> 
    <user name="Dev2" group="developer" address="[email protected]" /> 
    </users> 
    <groups> 
    <group name="developer" notification="change" /> 
    </groups> 

    <!-- Committers get an email for every build they commit code for --> 
    <converters> 
    <regexConverter find="$" replace="@ourcompany.com" /> 
    </converters> 
    <modifierNotificationTypes> 
    <NotificationType>always</NotificationType> 
    </modifierNotificationTypes> 
</email> 

So [email protected] und [email protected] eine E-Mail erhalten Wenn sich der Build-Status ändert, wird [svnuser] @ ourcompany.com eine E-Mail erhalten, wenn der Build, für den der Code festgeschrieben wurde, die Erstellung beendet.

Hinweis: Wenn der Build fehlschlägt, erhalten Svn-Benutzer, die Code seit dem letzten Erfolg festgeschrieben haben, weitere E-Mails, sobald ein Build abgeschlossen ist, bis der Build behoben ist.

+0

Ich akzeptiere deine Antwort, obwohl ich die Lösung nicht testen kann - wir sind vor einiger Zeit zu Hudson CI gewechselt. Wir waren einfach müde von Konfigurations-XML-Suppe und Regression Bugs. –

+0

@Igor: Hudson CI? Davon habe ich noch nie gehört. Obwohl ich CC ziemlich gut kenne, hat es viele Downside! Ich kann mir das mal ansehen, Prost für die Erwähnung. –

+0

http://hudson-ci.org/ ... viel freundlicher als CC.Es ist Java-basiert, aber es hat ein paar .NET-orientierte Plugins. Und es hat eine richtige GUI :) –

0
<email from="[email protected]" mailhost="xxxxxxxx.com" includeDetails="True"> 
      <users> 
       <user name="Dev Staff" group="group1" address="xxxxxxxxxxx"/> 
       <user name="QA Staff" group="group1" address="xxxxxxxxxxx"/> 
      </users> 
      <groups> 
       <group name="group1" notification="always"/> 
      </groups> 
      <modifierNotificationTypes> 
       <NotificationType>Always</NotificationType> 
      </modifierNotificationTypes> 
     </email> 

Dies funktioniert, aber vorsichtig sein. Wenn Sie jedem Entwickler eine E-Mail für jeden Build in einem fortlaufenden System senden, müssen Sie Ihre E-Mails ignorieren. Die einzige E-Mail, die ich an alle sende, ist der nächtliche Installer-Build.

+1

Alex, ich möchte KEINE E-Mail für JEDEN Build an JEDEN Entwickler senden. Ich denke, ich habe das zu Beginn der Frage klargestellt (siehe 1. und 2.). –

+0

werden nicht nur die E-Mails ignoriert, sondern abhängig von Ihren SMTP-Host-Regeln können Sie auf ISP-Ebene blockiert oder gefiltert werden! – TheOptimusPrimus

1

Ich denke, das macht was du willst ... wir laufen Version 1.4.3 so YMMV. Entwickler erhalten E-Mails nur dann, wenn sich der Status "Fest"/"Failed" ändert, während der PM bei jedem Build eine E-Mail erhält.