Tag SVN "Nightly" se comstack con CruiseControl.Net

¿Cómo podría hacer una compilation progtwigda por la noche u otra para CruiseControl.NET sin tener un proyecto duplicado?

En mi configuration actual, cada 60 segundos, estoy revisando el enlace usando Subversion, ejecutando MSBuild, luego NUnit o MSTest.

Me gustaría volver a comprometerme con SVN como una label, pero no lo quiero en cada compilation exitosa. Quiero que haga una creación nocturna o algún otro horario establecido. Para mí, parece un poco tedioso tener dos proyectos CruiseControl.Net con básicamente las mismas opciones. ¿Cuál es la mejor manera de manejar eso?

Como beneficio adicional, me gustaría que se compile como versión de lanzamiento y que los binarys se incluyan en la misma label.

La única forma que he encontrado hasta ahora es crear otro proyecto en el file ccnet.config que se basa en el resultado del primero … esto es lo que quiero decir.

El primer proyecto se crea de forma normal cada vez que un desarrollador ingresa cualquier código.

El segundo proyecto solo se ejecuta después de un time específico (por ejemplo, 11 p.m.) y solo se ejecutará SI el primer proyecto muestra una compilation exitosa.

Por lo tanto, estoy utilizando el segundo proyecto para realizar las testings de UI en Selenium durante la mitad de la noche, sin tener que ejecutarlos durante el día y ocupar la máquina de compilation para cuando los desarrolladores lo necesiten.

Esto es lo que he hecho para hacer esto: en mi file ccnet.config, mi segundo proyecto tiene esto como su configuration:

<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> 

Además, mi sección de control de fuente tiene esto:

 <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> 

… …

Por el que se establece en falso, para que el proyecto no elimine el código, pero usa lo que ya existe.

Luego, en mi tarea un poco más abajo, paso una bandera a NAnt para decirle que solo ejecute las testings de UI para mis proyectos, ya que el primer proyecto en el file ccnet.config ya ejecutó el process de compilation, pero luego ignora las testings de UI.

¿Esto ayuda en absoluto? Puedo expandirme aún más si este es el tipo de dirección en la que desea ingresar.

No tengo una solución para su problema con los proyectos ccnet duplicates. pero le diré cómo usamos ccnet (y estamos bastante contentos con eso).

tenemos 20 proyectos en el server de compilation y varias versiones de versiones anteriores. solo comenzamos las construcciones bajo demanda usando la aplicación cctray. entonces, después de que un desarrollador termina de implementar una característica, hace clic en el button "forzar compilation" y ccnet comienza a hacer lo suyo (comstackr, probar, labelr, copyr la salida de compilation en una unidad de networking, notificar a otros desarrolladores, …).

la ventaja es que los desarrolladores pueden decidir cuándo iniciar una compilation. los proyectos que no han cambiado no están construidos. los proyectos con trabajo en progreso pueden crearse varios compromisos más adelante, solo cuando un desarrollador cree que necesita una compilation.

Una idea que me viene a la mente para comenzar las comstackciones nocturnas sería usar la interfaz remota de ccnet (que también usa cctray), conectarla a la instancia de ccnet y llamar al método force-build-method a la medianoche.

concerniente a "cometer binarys a la misma label":

hay un problema en ccnet que ocasiona que a veces etiquete una revisión desde el tronco y, a veces, etiquete la copy de trabajo. lo hace dependiendo de si hubo cambios desde la última compilation (en cuyo caso label la revisión desde la troncal), o si no hubo cambios desde la última compilation (en cuyo caso label la copy de trabajo).

esto es bastante molesto porque nunca se sabe lo que se va a comprometer; en el primer caso, sus binarys no se comprometerán, en el segundo caso lo harán.

en realidad, hemos parcheado ccnet nosotros mismos para que siempre confirme la copy de trabajo para que tengamos un comportamiento determinista. una vez envié el parche pero nunca lo hice en …