2016-09-28 11 views
6

Próbuję użyć metod z pliku java.nio.file. *, Aby wykonać podstawowe operacje na plikach w potoku Jenkins. Bez względu na blok węzła, w którym istnieje kod, kod jest wykonywany na węźle głównym. W potoku zweryfikowałem, że różne bloki węzłów są poprawne - jednoznacznie identyfikują określone węzły. Jednak pathExists (i inny kod, który przenosi, kopiuje lub usuwa pliki) zawsze wykonuje się w węźle głównym. Wszelkie pomysły, co się dzieje lub jak to naprawić?Problem z potokami Jenkinsa i java.nio.file. * Metody

import java.nio.file.* 

String slavePath = 'C:\\Something\\only\\on\\slave\\node' 
String masterPath = 'D:\\Something\\only\\on\\master\\node' 

def pathExists (String pathName) 
{ 
    def myPath = new File(pathName) 
    return (myPath.exists()) 
} 

stage('One') 
{ 
    node ('slave') 
    { 
     bat returnStatus: true, script: 'set' 
     println (pathExists(slavePath))  // Should be true but is false. 
     println (pathExists(masterPath)) // Should be false but is true. 
    } 
    node ('master') 
    { 
     bat returnStatus: true, script: 'set' 
     println (pathExists(slavePath))  // false 
     println (pathExists(masterPath)) // true 
    } 
} 

Odpowiedz

4

Jest to specyfikacja skryptu potoku. Jest napisany w tutorial.

  • readFile krok ładuje plik tekstowy z przestrzeni roboczej i zwraca jego zawartość (nie spróbować użyć java.io.File metody - to będzie odnosić się do plików na wzorcu gdzie Jenkins jest uruchomiony, a nie w bieżący obszar roboczy ).

  • Istnieje również writeFile krok, aby zapisać zawartość do pliku tekstowego w obszarze roboczym

  • fileExists krok, aby sprawdzić, czy plik istnieje bez ładowania go.

Można wykorzystać te etapy Jenkins w węźle zamiast java.io.File lub java.nio.file.Files jak poniżej.

+0

Brakowało mi tego w dokumentacji. Więc jeśli dobrze rozumiem, mając pojedynczą metodę, która działa na węzłach nadrzędnych i podrzędnych, wewnątrz i na zewnątrz obszaru roboczego, w systemie Windows wymagałoby to użycia Groovy do uruchomienia pliku bat, który zwróci odpowiedź, być może przez uruchomienie pliku testowego PowerShell? – gaccardo

+0

Umm Nie rozumiem co masz na myśli. Czy nie jest to kolejne pytanie, które nie jest związane z problemem java.io.File? Dodałem przykład w mojej odpowiedzi, która działa tak, jak oczekiwałeś na wszelki wypadek. – arasio

+0

Zgodnie z [dokumentacją] (https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-fileexists-code-verify-if-file-exists-in-workspace), tylko fileExists działa dla plików w obszarze roboczym zadania. Kiedy początkowo próbowałem, tak było. Uruchomienie twojego przykładu działało poprawnie, nawet jeśli plik nie znajdował się w obszarze roboczym. Zweryfikowałem to w Jenkins 2.24 i 2.28. – gaccardo