Ответ 1

Самый полезный ответ

Существует плагин под названием плагин конфигурации SCM Sync.

Оригинальный ответ

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

EDIT:. Если вы найдете способ определить пользователя для изменения, сообщите нам.

РЕДАКТИРОВАТЬ 2011-01-10. Между тем есть новый плагин: плагин конфигурации SCM Sync. В настоящее время он работает только с subversion и git, но планируется поддержка большего количества репозиториев. Я использую его с версии 0.0.3, и он работает до сих пор.

Ответ 2

Обратите внимание, что Vogella имеет недавнее (январь 2014 года, по сравнению с вопросом OP январь 2010 года), и разные принимают это.
Полагайте, что плагин конфигурации SCM Sync может генерировать множество коммитов.
Таким образом, вместо того, чтобы полагаться на плагин и автоматизированный процесс, он управляет одной и той же функцией вручную:

Сохранение информации о работе Дженкинса в Git

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

Я создал следующий .gitignore файл для хранения только информации о вакансиях Git:

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

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

Alberto действительно рекомендую добавить также (в $JENKINS_HOME):

• jenkins own config (config.xml),
• Конфигурации плагинов jenkins (hudson*.xml) и
• пользовательские конфигурации (users/*/config.xml)

Ответ 3

Чтобы вручную управлять конфигурацией с помощью 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

Подробнее см. https://gist.github.com/780105 и http://bit.ly/i58rg2.

Ответ 4

Существует новый плагин SCM Sync Configuration, который делает именно то, что вы ищете.

Конфигурация синхронизации SCM Плагин Hudson направлена ​​на две основные функции:

• Храните синхронизированный файл config.xml(и других ресурсов) hudson с помощью Репозиторий SCM
• Отслеживать изменения (и автора), сделанные в каждом файле с сообщениями фиксации

Я еще не пробовал это, но выглядит многообещающим.

Ответ 5

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

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

git config --global user.name "Jenkins"
git config --global user.email "[email protected]"

Затем инициализируйте, добавьте и зафиксируйте основные файлы, такие как:

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

Наконец добавьте и зафиксируйте любые другие файлы, если это необходимо, затем отправьте их в удаленный репозиторий, где вы хотите сохранить файлы конфигурации.

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

Ответ 6

Я предпочитаю исключать все в домашней папке Jenkins, кроме файлов конфигурации, которые вы действительно хотите использовать в своей VCS. Вот файл .gitignore, который я использую:

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

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

Также стоит подумать о включении папки plugins. Должны быть включены довольные обновленные плагины...

В основном это решение облегчает будущие обновления Jenkins/Hudson, поскольку новые файлы не являются автоматически в области. Вы просто наброситесь на то, что вы действительно хотите.

Ответ 7

Ответ от Mark (fooobar.com/questions/49268/...) должен работать на SVN и Git (хотя конфигурация Git не работала для меня).

Но если вам нужно работать с Mercurial repo, создайте задание со следующим script:

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

Ответ 8

Я написал плагин, который позволяет вам проверить ваши инструкции Jenkins в исходном контроле. Просто добавьте файл .jenkins.yml с содержимым:

script:
    - make
    - make test

и Дженкинс сделает это:

Ответ 9

Более точный .gitignore, вдохновленный ответом от nepa:

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

Он игнорирует все, кроме .xml конфигурации .xml и самого .gitignore. (разница с nepa .gitignore заключается в том, что он не "неименовывает" все каталоги верхнего уровня (!*/), такие как logs/, cache/ и т.д.).

Ответ 10

Я полностью проверил в hudson, вы можете использовать это как отправную точку https://github.com/morkeleb/continuous-delivery-with-hudson

Есть преимущества для сохранения всего hudson в git. Все изменения конфигурации регистрируются, и вы можете легко протестировать тестовый тест на одной машине, а затем обновить другую машину с помощью git pull.

Мы использовали это как шаблон для нашей непрерывной установки доставки hudson на работе.

Отношения Morten