Почему выполнение пакетного файла не выполняется ТОЛЬКО В Jenkins с сообщением об ошибке, что сжатый файл .rar не существует?

Я создал простой пакетный файл, который создает резервную копию моего каталога Jenkins. Все работает без заминок, но как только я настроил свою сборку с помощью «Выполнить пакетную команду Windows», пакетный файл перестанет работать с сообщением «Файл уже существует или не может быть быть найденным (вольный перевод с немецкого).Однако локальный запуск скрипта с взаимодействием с пользователем работает просто отлично!

@echo off &color 1f && Title [Backup for Jenkins]

REM Path for Winrar
set path="C:\Program Files\WinRAR\";%path%

REM German Date-Format
set gerDate=%date:~0,2%-%date:~3,2%-%date:~6,4%

REM Winrar Backup
REM Base-Folder skipped
rar a -u -ep1 -r -agHH-MM -xC:\[Path for 1st skipped folder]\ -xC:\[Path for 2nd skipped folder] Jenkins_%gerDate%_.zip C:\[Path to compress all the following files]\*.*
color 2f & Title [Backup successful]

echo.
echo Move into different folder
echo.
move C:\[Path to the generated .zip file]\Jenkins*.zip C:\[Path to destination folder - network drive]\
echo.
echo Backup completed on%Date% %Time% 
echo.
pause

Я заметил, что мой скрипт временно хранится в папке C:\Users\[USER]\AppData\Local\Temp, и поскольку скрипт должен переместить сжатый .rar с помощью команды cmd "move" в другую папку, это может быть причиной моих проблем ... В любом случае, мой .rar не создается даже в папке Temp, так что это может быть и не так.


person Milan Dugovič    schedule 25.09.2018    source источник


Ответы (1)


Первая ошибка в строке:

set path="C:\Program Files\WinRAR\";%path%

Правильно было бы

set "path=C:\Program Files\WinRAR;%path%"

Путь к папке в списке путей к папкам, разделенных точкой с запятой, назначенный переменной среды PATH, не должен заключаться в двойные кавычки, кроме случаев, когда путь к папке содержит одну или несколько точек с запятой. Путь к папке также должен быть без обратной косой черты в конце.

Однако эта строка на самом деле не является проблемой и, конечно же, вообще не нужна, как это видно из кода командного файла ниже.

См. также Почему не выводится строка с "echo %var%" после использования "set var = text" в командной строке? для объяснения, почему один " слева от имени переменной среды и еще один " в конце строки аргумента.


Вторая ошибка — вся строка:

set gerDate=%date:~0,2%-%date:~3,2%-%date:~6,4%

Эта линия, скорее всего, является реальной проблемой.

Я предполагаю, что для вашей учетной записи пользователя настроена страна Германия, в результате чего формат даты dd.MM.yyyy означает 25.09.2018.

Но Jenkins работает как служба с системной учетной записью, которая, скорее всего, использует другой формат даты, например, английский, США, что приводит к строке даты Tue, 09/25/2018.

Таким образом, getDate — это Tu-, -9/25 вместо 25-09-2018, а / интерпретируется как разделитель каталогов, такой как \, который является реальным разделителем каталогов в Windows.

По этой причине Jenkins_%gerDate%_.zip становится при выполнении Jenkins Jenkins_Tu-, -9/25_.zip и Rar.exe не может найти в текущем каталоге подкаталог Jenkins_Tu-, -9 для создания файла 25_HH-mm.zip в этом каталоге.

См. также: Почему %date% дает другой результат в пакетном файле, выполняемом как запланированная задача?


Третья ошибка — использование Rar.exe с указанием расширения файла .zip. Руководство для консольной версии Rar.exe представляет собой текстовый файл Rar.txt в папке программных файлов WinRAR. В верхней части этого текстового файла можно прочитать, что Rar.exe поддерживает только формат файла архива RAR. Таким образом, все созданные архивы являются архивами RAR, а не ZIP, хотя расширение файла .zip.


Интересно видеть, что переключатель -ag используется с HH-MM, хотя Rar.exe также поддерживает добавление не только текущих часов и минут, но и текущей даты в настраиваемом формате с использованием -ag для архивирования имени файла перед расширением файла.

Таким образом, командная строка set gerDate=... вообще не нужна, что делает приведенный ниже пакетный код независимым от региональных настроек используемой учетной записи.


Далее в руководстве Rar.exe описывается, что *.* не интерпретируется как *, как это делает командный процессор Windows. *.* означает, что файл, добавляемый в архив, действительно должен иметь точку в имени файла, или Rar.exe игнорирует файл. Похоже, каталог нужно рекурсивно добавить в архив с обновлением существующих файлов в архиве и исключением двух каталогов. По этой причине следует использовать только * или не использовать подстановочный знак в конце пути к папке для архива, поскольку * является значением по умолчанию, если подстановочный знак не используется.

См. также Просто сжать 1 папку в пакетном режиме с помощью командной строки WinRAR? для объяснения, почему указанный путь к папке в коде пакетного файла ниже заканчивается обратной косой чертой.


Rar.exe может создать файл архива в любом существующем каталоге. Нет необходимости создавать его в текущем каталоге, а затем перемещать файл в каталог назначения.


Руководство Rar.txt внизу содержит возможные коды выхода.

Таким образом, можно проверить, произошла ли какая-либо ошибка с помощью if errorlevel 1, что означает, что код выхода больше или равен 1, как описано с помощью команды IF, выводимой при запуске в командной строке. окно if /?.

if not errorlevel 1 — наоборот, т. е. код выхода меньше 1, что означает равенство 0, поскольку Rar.exe никогда не завершается с отрицательным значением, как почти все приложения и команды.


Итак, давайте объединим всю эту информацию в новый пакетный файл:

@echo off
color 1f
title [Backup for Jenkins]

rem WinRAR backup, base folder skipped
"C:\Program Files\WinRAR\rar.exe" u -agYYYY-MM-DD_HH-MM -ep1 -r -inul -x"C:\[Path for 1st skipped folder]\" -x"C:\[Path for 2nd skipped folder]" "C:\[Path to destination folder - network drive]\Jenkins_.rar" "C:\[Path to compress all the following files]\"

if not errorlevel 1 color 2f & title [Backup successful]
echo Backup completed on %DATE% %TIME%
echo/
pause

Я также добавил -inul, который отключает весь вывод на консоль и неявно приводит к тому, что пользователь никогда не будет предлагать пользователю, например, использовать дополнительно переключатель -y, который в противном случае следует использовать здесь, например, при использовании -icdpq вместо -inul для получения выходных сообщений об ошибках, которые захватывает Дженкинс, но нет другая информация о состоянии.

person Mofi    schedule 25.09.2018