Спочатку спочатку наведіть курсор миші на сіру область нижче. Не частина відповіді, але абсолютно потрібно сказати:
Якщо у вас є сценарій оболонки, який "перевіряє, будує, розгортає" все сам, то чому ви використовуєте Дженкінс? Ви перераховуєте всі риси Дженкінса, які роблять його таким, яким він є. Можливо, ви також можете отримати cron або SVN-гачок після завершення виклику скрипта безпосередньо. Дженкінс, який займається оформленням SVN, має вирішальне значення. Це дозволяє запускати збірки лише тоді, коли є зміни (або в таймері, або вручну, якщо вам зручніше). Він відстежує зміни між збірками. Він показує ці зміни, тож ви можете бачити, яка збірка була для якого набору змін. Він надсилає електронний лист комітетам, коли їх зміни спричинили успішну або невдалу збірку (знову ж таки, як налаштовано). Він надішле електронних повідомлень, коли їхні виправлення виправлять невдалу збірку. І все більше. Архівні артефакти Дженкінса також роблять їх доступними за збірку безпосередньо за Дженкінсом. Хоча це не так важливо, як замовлення на SVN, це знову є невід'ємною частиною того, що робить його Дженкінсом. Те саме з розгортанням. Якщо у вас є єдине середовище, розгортання зазвичай відбувається в декількох середовищах. Дженкінс може відслідковувати, в якому середовищі розгорнута конкретна збірка (із специфічним набором змін SVN) за допомогою Акції. Ви все це випереджаєте. Це здається, що вам кажуть "ти повинен користуватися Дженкінсом", але ти цього не хочеш, і ти робиш це просто для того, щоб відмовитись від босів, щоб поставити галочку "так, я використав Дженкінса"
Коротка відповідь: вихідний код останньої команди кроку побудови виконавчої оболонки Дженкіна - це те, що визначає успіх / неуспіх кроку збірки . 0- успіх, anything else- невдача. Зауважте, це визначає успіх / провал кроку збирання , а не виконання всієї роботи . На успіх / невдачу всього виконання завдання може вплинути також кілька етапів складання, дії та додатки після складання.
Ви вже згадували Build step 'Execute shell' marked build as failure, тому ми зосередимось лише на одному кроці побудови. Якщо у вашому кроці зборки оболонки Execute є лише один рядок, який викликає ваш скрипт оболонки, тоді вихідний код сценарію оболонки визначатиме успіх / невдачу кроку збірки. Якщо у вас є більше рядків після виконання сценарію оболонки, уважно їх перегляньте, оскільки саме вони можуть стати причиною збою.
Нарешті, прочитайте тут виходи Jenkins Build Script після виконання тесту Google . Це не пов'язане безпосередньо з вашим запитанням, але зауважте, що частина про Дженкінс запускає крок побудови Execute Shell як сценарій оболонки з/bin/sh -xe
Це -eозначає, що скрипт оболонки завершиться з відмовою, навіть якщо не вдасться лише 1 команда, навіть якщо ви виконаєте перевірку помилок для цієї команди (оскільки сценарій закінчується до того, як він потрапить до вашої перевірки помилок). Це суперечить звичайному виконанню скриптів оболонки, які зазвичай друкують повідомлення про помилку для невдалої команди (або перенаправляють її на нуль та обробляють її іншими способами) та продовжують.
Щоб обійти це, додайте set +eдо верхнього сценарію оболонки.
Оскільки ви говорите, що ваш сценарій робить все, що належить зробити, швидше за все, команда, що не відповідає, знаходиться десь у кінці сценарію. Може, остаточне відлуння? Або копіювати артефакти десь? Не бачивши повного виходу консолі, ми просто здогадуємось.
Будь ласка, опублікуйте вихідний консольний запуск завдання, бажано, і сам сценарій оболонки, і тоді ми могли б точно сказати, яка строка не відповідає.