Is there a way to keep Hudson / Jenkins configurat

问题:

I am new to Hudson / Jenkins and was wondering if there is a way to check in Hudson's configuration files to source control.

Ideally I want to be able to click some button in the UI that says 'save configuration' and have the Hudson configuration files checked in to source control.

回答1:

Most helpful Answer

There is a plugin called SCM Sync configuration plugin.

---

Original Answer

Have a look at my answer to a similar question. The basic idea is to use the filesystem-scm-plugin to detect changes to the xml-files. Your second part would be committing the changes to SVN.

EDIT: If you find a way to determine the user for a change, let us know.

EDIT 2011-01-10 Meanwhile there is a new plugin: SCM Sync configuration plugin. Currently it only works with subversion and git, but support for more repositories is planned. I am using it since version 0.0.3 and it worked good so far.

回答2:

Note that Vogella has a recent (January 2014, compared to the OP's question January 2010) and different take on this.
Consider that the SCM Sync configuration plugin can generate a lot of commits.
So, instead of relying on a plugin and an automated process, he manages the same feature manually:

Storing the Job information of Jenkins in Git

I found the amount of commits a bit overwhelming, so I decided to control the commits manually and to save only the Job information and not the Jenkins configuration.
For this switch into your Jenkins jobs directory (Ubuntu: /var/lib/jenkins/jobs) and perform the “git init” command.

I created the following .gitignore file to store only the Git jobs information:

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

Now you can add and commit changes at your own will.
And if you add another remote to your Git repository you can push your configuration to another server.

Alberto actually recommend to add as well (in $JENKINS_HOME):

• jenkins own config (config.xml),
• the jenkins plugins configs (hudson*.xml) and
• the users configs (users/*/config.xml)

回答3:

To manually manage your configuration with Git, the following .gitignore file may be helpful.

# 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

See https://gist.github.com/780105 and http://bit.ly/i58rg2 for more details.

回答4:

There is a new SCM Sync Configuration plug-in which does exactly what you are looking for.

SCM Sync Configuration Hudson plugin is aimed at 2 main features :

• Keep sync'ed your config.xml (and other ressources) hudson files with a SCM repository
• Track changes (and author) made on every file with commit messages

I haven't actually tried this yet, but it looks promising.

回答5:

The way I prefer is to exclude everything in the Jenkins home folder except the configuration files you really want to be in your VCS. Here is the .gitignore file I use:

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

This ignores everything (*) except (!) .gitignore itself, the jobs/projects, the plugin and other important and user configuration files.

It's also worth considering to include the plugins folder. Annoyingly updated plugins should be included...

Basically this solution makes it easier for future Jenkins/Hudson updates because new files aren't automatically in scope. You just get on the screeen what you really want.

回答6:

You can find configuration files in Jenkins home folder (e.g. /var/lib/jenkins).

To keep them in VCS, first login as Jenkins (sudo su - jenkins) and create its git credentials:

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

Then initialize, add and commit the basic files such as:

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

also consider creating .gitignore with the following files to ignore (customize as needed):

# Git untracked files to ignore.

# Site-wide and root configuration files.
*.xml

# 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

Then add it: git add .gitignore.

When done, you can add job config files, e.g.

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

Finally add and commit any other files if needed, then push it to the remote repository where you want to keep the config files.

---

When Jenkins files are updated, you need to reload them (Reload Configuration from Disk) or run reload-configuration from Jenkins CLI.

回答7:

Answer from Mark (https://stackoverflow.com/a/4066654/142207) should work for SVN and Git (although Git configuration did not work for me).

But if you need it to work with Mercurial repo, create a job with following 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 [e-mail]
    hg push
fi

回答8:

I've written a plugin that lets you check your Jenkins instructions into source control. Just add a .jenkins.yml file with the contents:

script:
    - make
    - make test

and Jenkins will do it:

回答9:

A more accurate .gitignore, inspired by the reply from nepa:

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

It ignores everything except for .xml config files and .gitignore itself. (the difference to nepa's .gitignore is that it doesn't "unignore" all top-level directories (!*/) like logs/, cache/, etc.)

回答10:

I checked in hudson entirely, you could use this as a starting point https://github.com/morkeleb/continuous-delivery-with-hudson

There are benefits to keeping entire hudson in git. All config changes are logged and you can test the testup quite easily on one machine and then update the other machine(s) using git pull.

We used this as a boilerplate for our hudson continuous delivery setup at work.

Regards Morten