Tag SVN « nuit » Builds avec CruiseControl.Net

Question

Comment ferais-je une nuit ou autre construction prévue pour CruiseControl.NET sans avoir un projet en double?

Dans ma configuration actuelle, toutes les 60 secondes, je vérifie le réseau à l'aide de Subversion, MSBuild, puis NUnit ou MSTest.

Je voudrais revenir en SVN en tant que balise, mais je ne le veux pas sur chaque build réussi. Je veux qu'il fasse une compilation nocturne ou un autre programme. Pour moi, il semble un peu fastidieux d'avoir deux projets CruiseControl.Net avec essentiellement les mêmes options. Quelle est la meilleure façon de gérer cela? En guise de bonus, je voudrais qu'il soit construit en version release et qu'il commette les binaires dans la même balise.

Answer 1

La seule façon que j'ai trouvé jusqu'ici, est de créer un autre projet dans le fichier ccnet.config qui repose sur la sortie du premier ... voici ce que je veux dire.

Le premier projet construit comme normal chaque fois qu'un chèques-développeur dans le code.

Le deuxième projet ne s'exécute qu'après une durée spécifiée (par exemple 23 heures) et ne fonctionnera que si le premier projet montre une construction réussie. Par conséquent, j'utilise le deuxième projet pour faire les tests d'interface utilisateur dans Selenium au milieu de la nuit, sans les faire fonctionner pendant la journée et occuper la machine de construction quand les développeurs en ont besoin.

Voici ce que je vous ai fait faire ceci: Dans mon CCNet.fichier de configuration, mon deuxième projet a ce que ses réglages de:

<triggers> 
     <multiTrigger operator="And"> 
      <triggers> 
       <projectTrigger project="NameOfProject1" /> 
       <scheduleTrigger time="23:00" buildCondition="ForceBuild"> 
        <weekDays> 
         <weekDay>Monday</weekDay> 
         <weekDay>Tuesday</weekDay> 
         <weekDay>Wednesday</weekDay> 
         <weekDay>Thursday</weekDay> 
         <weekDay>Friday</weekDay> 
         <weekDay>Saturday</weekDay> 
        </weekDays> 
       </scheduleTrigger> 
      </triggers> 
     </multiTrigger> 
    </triggers> 

En outre, ma section de contrôle de code source a ceci:

<sourcecontrol type="multi"> 
<sourceControls> 
    <svn> 
     <trunkUrl>http://<my-svn-url>:81/svn/<my-project-name>/branches/1.13</trunkUrl> 
     <workingDirectory>c:\ccnet\<my-system-name>\<my-project-name></workingDirectory> 
     <cleanCopy>false</cleanCopy> 
    </svn> 

... ...

par ces choses le est mis à false, afin que le projet ne supprime pas le code, mais utilise ce qui existe déjà. Puis, dans ma tâche, un peu plus bas, je passe un drapeau à NAnt pour lui dire de ne lancer que les tests de l'interface utilisateur pour mes projets, car le premier projet dans le fichier ccnet.config a déjà exécuté la construction traiter à travers, mais ignore les tests d'interface utilisateur.

Est-ce que cela aide du tout? Je peux développer plus loin si c'est le genre de direction que vous voulez aller.

Answer 2

je n'ai pas une solution pour votre problème avec les doublons CCNet-projets. mais je vais vous dire comment nous utilisons ccnet (et nous sommes très heureux avec ça).

nous avons 20 projets sur le serveur de construction et plusieurs branches de libération des versions précédentes. nous commençons seulement à construire à la demande en utilisant l'application cctray. donc après qu'un développeur ait fini d'implémenter une fonctionnalité, il clique sur le bouton "force build" et ccnet commence à faire son truc (build, test, tag, copie de sortie de copie sur un lecteur réseau, notifier les autres développeurs, ...).

l'avantage est que les devs peuvent décider quand commencer une construction. les projets qui n'ont pas changé ne sont pas construits. Les projets avec work in progress peuvent être construits plusieurs fois plus tard, seulement lorsqu'un développeur pense qu'il a besoin d'une build. Une idée qui vient à l'esprit pour démarrer les builds nocturnes serait d'utiliser l'interface d'accès distant de ccnet (qui est également utilisée par cctray), de la connecter à l'instance ccnet et d'appeler la méthode force-build à minuit.

concernant « commettre des binaires à la même balise »:

il y a un problème dans CCNet qu'il provoque parfois de marquer une révision du tronc et parfois pour marquer la copie de travail. il le fait en fonction de s'il y a eu des modifications depuis la dernière construction (dans ce cas, il balise la révision depuis le tronc), ou s'il n'y a pas eu de changements depuis la dernière construction (dans ce cas, il balise la copie de travail).

C'est assez ennuyeux parce que vous ne savez jamais ce qui va être commis - dans le premier cas vos binaires ne seront pas validés, dans le second cas ils le seront. Nous avons en fait corrigé ccnet nous-mêmes pour qu'il commette toujours la copie de travail afin que nous obtenions un comportement déterministe. J'ai une fois soumis le patch mais il ne l'a jamais fait ...