0

J'ai un travail dans Hudson qui s'appuie sur un esclave Windows XP. Je sais que les liens symboliques ne sont pas possibles (directement) sous Windows XP, et j'essaie donc d'utiliser des jonctions à la place. J'ai écrit un script batch:Création de jonctions dans Windows pour Hudson build

@echo off 
if "%1" == "" goto ERROR1 
if "%2" == "" goto ERROR2 
goto create 

:create 
echo Creating junction for %1 at %2 
if exist %2 junction -q -d %2 
md %2 
junction -q %2 %1 
goto :eof 

:ERROR1 
echo Source directory not specified 
goto :eof 

:ERROR2 
echo Destination directory not specified 
goto :eof 

Dans mon travail, quand je l'appelle ce script, il se bloque à la ligne echo Creating junction for %1 at %2. Ceci est mon Hudson "Exécuter de Windows Batch Command":

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64 

copy C:\Data\Scripts\slink.bat . 
call slink.bat C:\Data\3rdParty64 3rdParty 
call slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core 

... et c'est la sortie:

C:\Data\Hudson\dev\workspace\Common_Windows\label\DFWW9202>call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64 
Setting environment for using Microsoft Visual Studio 2010 x64 tools. 

1 file(s) copied. 
Creating junction for C:\Data\3rdParty64 at 3rdParty 

Toutes les idées? (si ce n'est pas le bon site, s'il vous plaît rediriger..désolé et merci!)

Répondre

0

Peu importe, je l'ai trouvé si quelqu'un d'autre cherche - j'ai changé le "appel" à slink.bat à "démarrer/B", et a ajouté des chemins complets, donc:

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64 
start /B C:\Data\Scripts\slink.bat C:\Data\3rdParty64 3rdParty 
start /B C:\Data\Scripts\slink.bat slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core 
2

Cette procédure n'a pas fonctionné pour moi, mais j'ai affiné le vrai problème. Un peu d'arrière-plan: La toute première fois que le programme "junction.exe" est exécuté par un utilisateur sur un ordinateur Windows, il affiche un accord de licence utilisateur final (CLUF) avec un bouton d'accord. Une fois que l'utilisateur clique sur le bouton "Accepter", il peut utiliser l'utilitaire normalement. Junction.exe stagnait pour Hudson parce que le service était exécuté en tant que "Utilisateur par défaut", et "Utilisateur par défaut" n'a jamais cliqué sur le bouton Accepter. Cela a causé junction.exe à caler invisiblement et indéfiniment, en attendant ce clic, qui bien sûr n'arrivera jamais. La manière dont nous l'avons corrigé consistait à configurer le système pour qu'il exécute le service Hudson en tant que compte bien connu, et non en tant qu'utilisateur par défaut. Ensuite, nous avons ouvert une session sur la machine Windows sous ce compte, exécuté junction.exe, cliqué sur le bouton Accepter, puis déconnecté. Depuis, junction.exe fonctionne parfaitement dans Hudson depuis le début.

L'autre option consiste à passer à Windows Server 2008. On me dit que la version a la fonctionnalité de jonction dans un nouvel utilitaire «mklink» qui est intégré dans le système d'exploitation lui-même et n'a pas de CLUF.

+0

Merci! J'ai beaucoup tripoté avec ça, et ça a finalement commencé à fonctionner ... Je ne suis pas sûr de ce que c'était parce que tant de choses ont changé depuis, mais je suis content que vous ayez réussi. Merci de l'avoir mis ici! – Sagar

4

La meilleure façon de résoudre ceci est de: passer/accepter un argument de ligne de commande à la commande de jonction.

par exemple: de jonction% 2% 1/accepteula

+3

Pour le garder séparé de la logique de script actuelle, et le placer comme une initialisation/installation à la place, on peut utiliser 'junction/accepteula> NUL'. De cette façon, la sortie (utilisation, informations d'aide) est supprimée pendant que le CLUF est encore accepté. – Kissaki