Чи є спосіб зберегти файли конфігурації Хадсона / Дженкінса у контролі джерела?


140

Я новачок у Хадсон / Дженкінс і мені було цікаво, чи є спосіб перевірити файли конфігурації Хадсона для управління джерелом.

В ідеалі я хочу мати можливість натиснути кнопку в інтерфейсі користувача, яка говорить "зберегти конфігурацію", і щоб файли конфігурації Хадсона були зареєстровані для управління джерелом.


Або ви можете зберігати цю інформацію в
репортажі


Перевірте: каталог HUDSON_HOME для структури файлів Jenkins.
kenorb

Відповіді:


62

Найкорисніша відповідь

Існує плагін, який називається модулем конфігурації SCM Sync .


Оригінальний відповідь

Погляньте на мою відповідь на подібне запитання. Основна ідея - використовувати файлову систему-scm-плагін для виявлення змін у xml-файлах. Ваша друга частина буде вносити зміни до SVN.

РЕДАКТУВАННЯ. Якщо ви знайдете спосіб визначити користувача для зміни, повідомте нас про це.

EDIT 2011-01-10 Тим часом з'явився новий плагін: плагін налаштування SCM Sync . В даний час він працює лише з subversion та git, але планується підтримка більшої кількості сховищ. Я використовую його з версії 0.0.3, і він працював добре до цих пір.


2
Я прошу відрізнятись: плагін має деякі основні недоліки, якщо ви використовуєте git та працюєте у складних умовах: 'Якщо ви використовуєте Git, то вам слід використовувати ключ SSH із замовчуванням. Це "id_rsa". У SCM Sync немає можливості вказувати шлях ssh для ключа. SCM Sync використовує .ssh / id_rsa з домашнього каталогу власника процесу jenkins. ' від [ wiki.jenkins-ci.org/display/JENKINS/…
Бен Хатчісон

2
Плагін налаштування синхронізації SCM несумісний із плагіном Subversion> = 2.0 (за проблеми.jenkins-ci.org / browse / JENKINS-21640 ).
Нік Джонс

1
Я не рекомендую користуватися цим плагіном, після установки інсталяції не з'явилися. Здається, що у цьому плагіні багато помилок, і оновлення / виправлення не надто часто отримує. Уникайте "плагіна для налаштування синхронізації SCM"
vikramvi

1
@vikramvi, яку альтернативу ти пропонуєш?
Ігор Родрігес

1
@IgorRodriguez Оскільки робота dnkins не зазнає частих змін у порівнянні з кодом проекту; Я роблю зміни в github вручну.
vikramvi

38

Зауважимо, що Vogella має нещодавнє (січень 2014 р. Порівняно з питанням ОП січень 2010 р.) І по-різному сприймає це.
Врахуйте, що плагін конфігурації SCM Sync може генерувати безліч комісій.
Отже, замість того, щоб покладатися на плагін і автоматизований процес, він управляє тією ж функцією вручну:

Зберігання інформації про роботу Дженкінса в Git

Я вважав, що кількість комісій трохи переважна, тому я вирішив контролювати комірки вручну і зберігати лише інформацію про роботу, а не конфігурацію Дженкінса.
Для цього перемкніть у свій каталог завдань Jenkins (Ubuntu:) /var/lib/jenkins/jobsта виконайте команду “ git init”.

Я створив такий .gitignoreфайл, щоб зберігати лише інформацію про завдання Git:

builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
modules/
*.log

Тепер ви можете додавати та вносити зміни за власним бажанням.
І якщо ви додасте ще один пульт до свого сховища Git, ви можете перенести конфігурацію на інший сервер.

Альберто фактично рекомендую додати також (у $JENKINS_HOME):

  • власні конфігурації jenkins ( config.xml),
  • модулі jenkins configs ( hudson*.xml) та
  • налаштування користувачів ( users/*/config.xml)

Чи не зберігатимуть конфігурації користувача, не піддавайте маркери API простого тексту у своїх config.xml?
Бун

@Boon Я не знаю насправді, оскільки мені не довелося використовувати токен API нещодавно. Це може бути хорошим питанням самостійно для вас.
VonC

2
Після деяких досліджень виявляється, що маркери API зашифровані в XML, тому це не загрожує безпеці.
Бун

19

Щоб вручну керувати вашою конфігурацією за допомогою Git, може бути корисним наступний файл .gitignore.

# Miscellaneous Hudson litter
*.log
*.tmp
*.old
*.bak
*.jar
*.json

# Generated Hudson state
/.owner
/secret.key
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/

# Tools that Hudson manages
/tools/

# Extracted plugins
/plugins/*/

# Job state
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber

Детальніше про це див. У GistHub Gist та у цьому блозі .


14

Існує новий плагін SCM Sync Configuration, який робить саме те, що ви шукаєте.

Конфігурація модуля синхронізації SCM Плагін Хадсона спрямований на дві основні характеристики:

  • Продовжуйте синхронізувати свої файли config.xml (та інші ресурси) hudson із сховищем SCM
  • Відстежуйте зміни (та автора), внесені у кожен файл із повідомленнями про фіксацію

Я ще цього ще не пробував, але це виглядає багатообіцяюче.


3
Мене зацікавить робоча конфігурація плагіна SCM Sync Configuration з Git, я спробував декілька конфігурацій, і я просто не міг змусити його працювати (а повідомлення про помилки в журналах були в кращому випадку не корисними).
Себастьяно Пілла

8

Ви можете знайти конфігураційні файли в домашній папці Дженкінса (наприклад /var/lib/jenkins).

Щоб зберегти їх у VCS, спочатку увійдіть як Jenkins ( sudo su - jenkins) та створіть свої git-облікові дані:

git config --global user.name "Jenkins"
git config --global user.email "jenkins@example.com"

Потім ініціалізуйте, додайте та виконайте основні файли, такі як:

git init
git add config.xml jobs/ .gitconfig
git commit -m'Adds Jenkins config files' -a

також розглянути можливість створення .gitignoreз наступними файлами для ігнорування (налаштування за потребою):

# Git untracked files to ignore.

# Cache.
.cache/

# Fingerprint records.
fingerprints/

# Working directories.
workspace/

# Secret files.
secrets/
secret.*
*.enc
*.key
users/
id_rsa

# Plugins.
plugins/

# State files.
*.state

# Job state files.
builds/
lastStable
lastSuccessful
nextBuildNumber

# Updates.
updates/

# Hidden files.
.*
# Except git config files.
!.git*
!.ssh/

# User content.
userContent/

# Log files.
logs/
*.log

# Miscellaneous litter
*.tmp
*.old
*.bak
*.jar
*.json
*.lastExecVersion

Потім додати: git add .gitignore.

Після закінчення можна додати файли конфігурації завдання, наприклад

shopt -s globstar
git add **/config.xml
git commit -m'Added job config files' -a

Нарешті, додайте та заповніть будь-які інші файли, якщо потрібно, а потім пересуньте їх до віддаленого сховища, де ви хочете зберегти конфігураційні файли.


Коли файли Дженкінса оновлюються, вам потрібно їх перезавантажити ( Перезавантажити конфігурацію з диска ) або запустити reload-configurationвід Дженкінс CLI.


Чому виключені конфігурації на сайті? Я бачу, що інші відповіді включають їх.
Вінсент Бельтман

@kenorb Я б її знову виключив. Рядок коментарів вище *.xmlне змінює правило, а git ігнорує всі XML-файли, в тому числі config.xmlз jobsкаталогу, після чого git statusмовчки ігнорує будь-який новий проект.
Миколасан

5

Я вважаю за краще виключати все з домашньої папки Дженкінса, за винятком файлів конфігурації, які ви дійсно хочете мати у своєму VCS. Ось .gitignoreфайл, який я використовую:

*
!.gitignore
!/jobs/*/*.xml
!/*.xml
!/users/*/config.xml
!*/

При цьому ігнорується все ( *), крім ( !) .gitignore, самих завдань / проектів, плагіну та інших важливих та конфігураційних файлів користувача.

Також варто розглянути можливість включення pluginsпапки. Дратівливо оновлені плагіни повинні бути включені ...

В основному це рішення полегшує майбутні оновлення Дженкінса / Хадсона, оскільки нові файли автоматично не мають обсягу. Ви просто отримаєте на екрані те, що ви дійсно хочете.


5

Більш точна .gitignore, натхненна відповіддю від nepa :

*
!.gitignore
!/jobs/
!/jobs/*/
/jobs/*/*
!/jobs/*/config.xml
!/users/
!/users/*/
/users/*/*
!/users/*/config.xml
!/*.xml

Він ігнорує все, крім .xmlфайлів конфігурації та .gitignoreсамого себе. (Різниця в Непско «и в .gitignoreтому , що він не" ігнорувати "все каталоги верхнього рівня ( !*/) , як logs/, cache/і т.д.)


2

Відповідь від Mark ( https://stackoverflow.com/a/4066654/142207 ) має працювати для SVN та Git (хоча конфігурація Git не працювала для мене).

Але якщо вам це потрібно для роботи з Mercurial repo, створіть роботу з наступним сценарієм:

hg remove -A || true
hg add ../../config.xml
hg add ../../*/config.xml
if [ ! -z "`hg status -admrn`" ]; then
    hg commit -m "Scheduled commit" -u fill_in_the@blank.com
    hg push
fi

2

Я написав плагін , за допомогою якого ви можете перевірити свої вказівки Дженкінса на контроль джерел. Просто додайте .jenkins.ymlфайл із вмістом:

script:
    - make
    - make test

і Дженкінс зробить це:

введіть тут опис зображення


0

Я повністю зареєструвався в Гудзоні, ви можете використовувати це як вихідну точку https://github.com/morkeleb/continuous-delivery-with-hudson

Є користь утримувати весь гудзон в git. Усі зміни конфігурації реєструються, і ви можете легко протестувати тестування на одній машині, а потім оновити іншу машину (и) за допомогою git pull.

Ми використовували це як котельну плиту для налаштування безперервної доставки гудзонів на роботу.

З повагою Мортен

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.