svn - msc - crucerosnet es confiable

Ejecutando el Control de Cruceros.NET como un Servicio (4)

He estado configurando y probando CCNet por un tiempo ahora usando Virtual PC para alojarlo. Todo fue bien y se decidió transferir la configuración a la ubicación de un servidor, que fue tan bien como podría esperarse. Algunos ajustes y patadas y lo tenía funcionando como antes.

El problema es que ahora necesitamos ejecutar CCNet como un servicio que está resultando problemático.

Configuré un usuario de nivel de dominio con los mismos derechos de acceso que yo (después de todo, la aplicación de consola se ha estado ejecutando como yo durante aproximadamente 3 meses) y configuré el servicio para que se ejecute bajo ese usuario.

¡Empecé el servicio y se colgó! [No te aburriré con los detalles de forzar el servicio para detener y cerrar los enchufes que se mantuvieron abiertos]. Cuando finalmente pude volver a ejecutar la consola, hice un ''Ejecutar como'' e ingresé los detalles del usuario ''cruisecontrol'', presioné OK y vi que había un problema para acceder al SVN a través de https. Lo he ordenado ejecutando IE como ''cruisecontrol'', navegando hasta el repositorio y aceptando / instalando el certificado. A continuación, cuando ejecuté la aplicación de la consola como ''cruisecontrol'', se cuelga después de las siguientes líneas:

2009-01-15 16:55:50,994 [Pepsi Webservices:DEBUG] Running Subversion with arguments : log --xml --limit 1 https://ash-dev-005.[path to trunk]

2009-01-15 16: 55: 51,478 [Servicios web de Pepsi: DEPURTO] Dominio de autenticación: https: // ash-dev-005. [Ruta al depósito] Repositorios de subversión

Después de que se agote el tiempo de espera, puedo cerrar la consola, ejecutarla de manera normal (es decir, como yo) y funciona bien. Intenté iniciar sesión en el servidor como el usuario de ''cruisecontrol'' e intenté ejecutar la consola pero con el mismo resultado.

Ahora, aquí está la cosa: esta mañana entré al servidor como el usuario de ''cruisecontrol'' y abrí una ventana de comando. Navegué hasta el maletero de mi proyecto y escribí ''svn update'' y me pidieron una contraseña.

Esto no es sorprendente, pero la línea arriba de ese mensaje fue la línea ''Authentication realm: ...'' ¡arriba! Al mirar el archivo de registro, con toda seguridad justo después de que CCNet mata el proceso, aparece una solicitud de contraseña. ¿Está CCNet / SVN esperando una entrada de contraseña y luego agotando el tiempo de espera? Si es así, ¿por qué no está utilizando el que está en el archivo de configuración?

Ingresé la contraseña y la actualización prosiguió sin ningún problema (por lo que el usuario de cruisecontrol tiene permisos para acceder al repositorio desde el servidor). Volví a ingresar el comando y no se me solicitó por segunda vez, así que intenté abrir una nueva ventana de comando y volver a ejecutar el comando; aún no me pidieron una contraseña, así que me desconecté y volví a ingresar (como cruisecontrol) y lo intenté nuevamente, pero aún no me lo pidieron .

La buena noticia es que cuando ejecuto la aplicación de consola como el usuario de cruisecontrol (ya sea que haya iniciado sesión como cruisecontrol o simplemente que utiliza Run As) todo parece estar bien.

Entonces, ¿cuál es mi pregunta? Bueno, ¿por qué CCNet no usa la contraseña en el archivo de configuración? ¿Cómo se solucionó el problema al ingresar la contraseña en el símbolo del sistema (y persistirá)?

Cualquier sugerencia / idea apreciada.

Hmmm - Pude haber respondido mi propia pregunta aquí (o no, solo el tiempo lo dirá).

Por alguna razón, CCNet no parece estar usando la credencial en el archivo de configuración (no sé por qué). Cuando llama a SVN, espera que se ingrese una contraseña, incluso si el usuario no puede verla, y luego agota el tiempo cuando no la recibe.

Al acceder a SVN desde la línea de comandos, la solicitud de contraseña es visible y puede ingresarse; además, la contraseña se almacena en caché en% app_data% / Subversion / auth / svn.simple dentro de un archivo cifrado para ese usuario. Esta es la razón por la cual los comandos subsiguientes no solicitan una contraseña y por qué la aplicación de la consola se ejecutará sin problemas.

Voy a configurar CCService ahora, así que espero que esto funcione tan bien como lo hace la aplicación de consola ahora.

Si has tenido experiencias similares, házmelo saber. Mientras tanto, puedo plantear el problema con ThoughtWorks.

Por lo que recuerdo, cuando ejecuta cc.net como un servicio, usa otro archivo de configuración luego cuando lo ejecuta como una aplicación de consola. (ccservice.exe.config en lugar de cc.exe.config).

Dave, es bastante fácil diagnosticar si CruiseControl está usando la contraseña en el archivo de configuración o no, ya que verás la línea de comando en el registro y el parámetro de contraseña real y la contraseña si se está utilizando, y se pasarán a svn. Si tiene la contraseña y el usuario en el archivo de configuración y no se están transfiriendo, lo primero que comprobaré es que su archivo de configuración es válido y que el archivo de configuración en el sistema de archivos es lo que realmente se está utilizando. Si realiza un cambio no válido en el archivo de configuración, CC.NET solo lo ignora, siempre y cuando el servicio se esté ejecutando y simplemente siga usando la versión que ha almacenado en caché internamente sin advertencias ni mensajes. Entonces, de nuevo, la única manera de verificar es mirar la configuración a través del tablero web y asegurarse de que refleje lo que espera, o puede revertir el servicio en qué punto se detendrá y señalar su error. Sin embargo, al final puedes solucionar esto como lo hiciste almacenando en caché la contraseña con subversión.

Relacionado con la respuesta de Frederik: en nuestro servidor, especificamos las credenciales de subversión en el proyecto en sí. El bloque de control de fuente para uno de estos proyectos se vería así:

<sourcecontrol type="svn"> <trunkUrl>http://myserver/svn/myproject/trunk</trunkUrl> <workingDirectory>C:/source/MyProject</workingDirectory> <username>foo</username> <password>bar</password> <autoGetSource>true</autoGetSource> </sourcecontrol>