Изграждане само ако промените на SCM са зададени на true в задачата на jenkins, но не се изграждат с най-новото ангажиране

Имам работа BuildApp с компилация (MultiJob Phase), която извиква друга работа BuildAppJar за изграждане на буркан. В заданието BuildApp „Изграждане само ако SCM се промени“ е зададено на true. Очаквам заданието BuildAppJar да изгради jar файл с последния комит, тъй като заданието BuildApp е конфигурирано да изгражда, когато SCM се промени. Но това не се случва. Вместо това получавам този дневник, в който се казва „подзаданието няма промени от последното изграждане“. Защо е така? Някаква идея? Не трябва ли Дженкинс да изгражда с най-новия ангажимент на код? Използвам Git.

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
[WS-CLEANUP] Done
    >> Job status: [BuildAppJar] subjob has no changes since last build.

Благодаря.


jenkins build version-control
person Tim    schedule 25.02.2019    source източник

Отговори (2)


arrow_upward
1
arrow_downward

Това може да се дължи на този бъг (вярвам, че и двата са един и същ проблем):

https://issues.jenkins-ci.org/browse/JENKINS-50168

https://issues.jenkins-ci.org/browse/JENKINS-55524

Симптомът е, че Jenkins проверява две хранилища, но не проверява правилното за промени. Добавете своя „git polling log“ (или, в зависимост от вашия плъгин, какъвто и да е регистрационен файл, който се появява в долната част на списъка над вашата хронология на компилирането) за потвърждение. Не намерих решение.

Webhooks (gitlab, bitbucket или каквото и да е друго) всъщност не карат Дженкинс да изгради определен ангажимент - webhook просто уведомява Дженкинс, че нещо има промени, и Дженкинс анкетира хранилището, за да види дали тази промяна трябва да задейства изграждане. В моя случай Дженкинс получава куката, анкетира репото, след това анкетира друго репо (също използвано от тази работа, но рядко актуализирано) и го проверява за промени. Така че трябва да имате отметка на „Build when a change is pushed to GitLab“ и „Poll SCM“.

За дълъг списък с други възможности проверете https://issues.jenkins-ci.org/browse/JENKINS-17614

person andrew lorien    schedule 26.02.2019
comment
Благодаря за отговора. Използвам gitlab webhook, така че всеки път, когато се случи натискане, той ще направи POST заявка до Дженкинс за изграждане на BuildApp задание. Когато преглеждам заявката за публикация на gitlab, тя е правилна. Както посочихте, проблемът изглежда е в Дженкинс. Не съм сигурен дали разбирам опцията Build only if SCM промени. Според етикета си помислих, че плъгинът за много задачи проверява git repo дали има скорошен ангажимент след последното компилиране. Но въз основа на бърз преглед на кода на приставката за много задачи, той дори не проверява git repo. - person Tim; 26.02.2019
comment
Отговорът е актуализиран с някои неща, които вероятно вече сте знаели за уеб куките, и няколко предложения - person andrew lorien; 26.02.2019
comment
Дори след като бяха проверени както Build when a change is pushed to GitLab, така и Poll SCM, той не изгради jor. Като заобиколно решение добавих нов етап в моя процес, за да изтрия хронологията на изграждането преди изграждането. След това построи буркан. - person Tim; 26.02.2019

arrow_upward
0
arrow_downward

Работи! Проблемът е - Дженкинс не може да открие промени в клона на подзаданието. Трябва да извършите, за всяко подзадание, проучване на SCM или да уведомите Дженкинс с помощта на WebHook.

Пример за моето използване с WebHook:

  1. Инсталирайте SCM Skip Plugin (https://github.com/jenkinsci/scmskip-plugin), за да избягвайте автоматично изграждане след насочване към вашия клон.

  2. Във вашите конфигурации на проекти за подработа:

    раздел Тригери за изграждане:

    • check "Build when a change is pushed to GitLab. GitLab webhook URL:"
    • проверете "Poll SCM" (без график).
    • щракнете върху бутона „Разширени“ и проверете дали опцията „Активиране [ci-skip]“ е отметната (трябва да бъде отметната по подразбиране).

    раздел Среда за изграждане:

    • отметнете "SCM Skip".

  3. В проекта GIT добавете WebHook, който се намира в Настройки -> WebHooks.

    • put URL: <jenkins_url>/gitlab/notify_commit
    • отметнете „Push събития“

  4. В конфигурации за множество задачи:

    раздел Специфична конфигурация за множество задачи:

    • check "Poll subjobs in addition to multijob when polling"

    раздел Тригери за изграждане:

    • проверете "Poll SCM" (без график).

  5. Извършете промените си със съобщение, което съдържа думата [ci-skip], за да пропуснете автоматичното изграждане.

Сега можете да натискате промени във вашия клон, Дженкинс ще бъде уведомен и изграждането ще бъде пропуснато. След това стартирайте MultiJob.

person Oleksandr Bodashko    schedule 02.04.2020