私はHudson / Jenkinsを初めて使用し、Hudsonの構成ファイルをソース管理にチェックインする方法があるかどうか疑問に思っていました。

理想的には、UIの「構成を保存」というボタンをクリックして、Hudson構成ファイルをソース管理にチェックインできるようにしたいです。

最も役立つ回答

SCM同期構成プラグインと呼ばれるプラグインがあります。

元の回答

同様の質問に対する私の答えを見てください。基本的な考え方は、filesystem-scm-pluginを使用してxml-filesへの変更を検出することです。2番目の部分は、SVNへの変更のコミットです。

編集：変更するユーザーを特定する方法を見つけた場合は、お知らせください。

編集2011-01-10一方、新しいプラグインがあります：SCM同期構成プラグイン。現在、subversionとgitでのみ機能しますが、より多くのリポジトリのサポートが計画されています。私はバージョン0.0.3から使用していますが、これまでのところうまくいきました。

Vogellaは最近（2014年1月、OPの質問2010年1月と比較）、これについて異なる見方をしていることに注意してください。SCM同期構成プラグインが多くのコミットを生成できることを
考慮してください。 したがって、プラグインと自動化プロセスに依存する代わりに、彼は同じ機能を手動で管理します。

Jenkinsのジョブ情報をGitに保存する

コミットの数が少なすぎるので、手動でコミットを制御し、Jenkins構成ではなくジョブ情報のみを保存することにしました。
この場合、Jenkinsジョブディレクトリ（Ubuntu：）に切り替え/var/lib/jenkins/jobs、「git init」コマンドを実行します。

次の.gitignoreファイルを作成して、Gitジョブ情報のみを保存しました。

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

これで、自分の意志で変更を追加してコミットできます。
また、Gitリポジトリに別のリモートを追加すると、構成を別のサーバーにプッシュできます。

アルベルトは実際に追加することをお勧めします（内$JENKINS_HOME）：

• jenkins自身の設定（config.xml）、
• jenkinsプラグイン設定（hudson*.xml）および
• ユーザー設定（users/*/config.xml）

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

詳細については、このGitHub Gistとこのブログ投稿を参照してください。

新しいSCM Sync Configurationプラグインがあり、まさにあなたが探しているものを実行します。

SCM同期構成Hudsonプラグインは、2つの主な機能を対象としています。

• config.xml（およびその他のリソース）hudsonファイルをSCMリポジトリと同期します
• コミットメッセージですべてのファイルに加えられた変更（および作成者）を追跡する

私はまだこれを試していませんが、有望に見えます。

構成ファイルはJenkinsホームフォルダー（例：）にあります/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

最後に、必要に応じて他のファイルを追加してコミットし、構成ファイルを保持するリモートリポジトリにプッシュします。

Jenkinsファイルが更新されたら、それらをリロードする（Reload Configuration from Disk）かreload-configuration、Jenkins CLIから実行する必要があります。

私が好む方法は、実際にVCSに含めたい構成ファイルを除いて、Jenkinsホームフォルダー内のすべてを除外することです。これが.gitignore私が使用するファイルです：

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

これにより、*（!）.gitignore自体、ジョブ/プロジェクト、プラグイン、その他の重要なユーザー構成ファイルを除くすべて（）が無視されます。

pluginsフォルダーを含めることも検討する価値があります。迷惑なように更新されたプラグインを含める必要があります...

基本的にこのソリューションでは、新しいファイルが自動的にスコープに含まれないため、将来のJenkins / Hudsonの更新が容易になります。あなたは本当にあなたが本当に欲しいものをスクリーンに乗るだけです。

nepa.gitignoreからの返信に触発されたより正確な：

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

構成.xmlファイルと.gitignoreそれ自体を除くすべてを無視します。（に違いNEPAのは、.gitignoreそれがすべてのトップレベルのディレクトリ（ 『除外を解除』しないということである!*/ように）logs/、cache/など）

Markからの回答（https://stackoverflow.com/a/4066654/142207）は、SVNおよびGitで機能するはずです（Git構成は機能しませんでした）。

ただし、Mercurialリポジトリで作業する必要がある場合は、次のスクリプトを使用してジョブを作成します。

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

私がきたプラグインを書かれたソース管理にあなたのジェンキンス命令を確認できます。.jenkins.yml内容を含むファイルを追加するだけです。

script:
    - make
    - make test

ジェンキンスはそれを行います：

ハドソンを完全にチェックインしました。これを出発点として使用できます。https：//github.com/morkeleb/continuous-delivery-with-hudson

ハドソン全体をgitで維持することには利点があります。すべての構成変更がログに記録され、1台のマシンでテストを非常に簡単にテストしてから、git pullを使用して他のマシンを更新できます。

これを、ハドソンの継続的デリバリー設定の定型文として使用しました。

よろしく