Git clone on jenkins master, copy to slave

I’ve set up a CI server running jenkins and a slave with a replica of our production environment. I’m running into a pesky little problem though: Jenkins apparently runs git clone on the slave which would mean that every slave should have it’s publickey added to GitHub.

To me this sounds like a pretty weird architecture design. I would prefer the master server (which has all my credentials) to clone/checkout and copy the workspace to the slave. But after quite some Googling I haven’t found a way to do this yet. I have found the Copy to slave plugin but that doesn’t prevent the slave from failing on a git clone.

  • Change Avatar Next to GitHub Username (For Commits)
  • Reuse a Part of a git Repository
  • What is “origin” in Git?
  • How to emulate git log --decorate's different colors per branch-type
  • How to trigger a Jenkins build when a push is made to a private github repository
  • fatal: remote origin already exists - GitHub
  • I hope someone know a way to achieve this because setting up GitHub publickeys for every slave sounds ridiculous.

  • How can I remove an entry in global configuration with git config?
  • GitHub push error - 'git media update'
  • Getting current Git commit version from within Rails app?
  • How to configure Git post commit hook
  • git fatal: SHA1 COLLISION FOUND
  • How to show a file from a specific commit that has been renamed between that commit and HEAD?
  • 2 Solutions collect form web for “Git clone on jenkins master, copy to slave”

    Jenkins apparently runs git clone on the slave which would mean that every slave should have it’s publickey added to GitHub.

    Why not use one deployment key (for all Jenkins agent to use) for accessing your repo?

    A deploy key is an SSH key that is stored on the server and grants access to a single repository on GitHub.
    This key is attached directly to the repository instead of to a user account.


    • Anyone with access to the server has access to deploy the repository
    • Users don’t have to change their local SSH settings


    • Deploy keys only grant access to a single repository, more complex projects may have many repositories to pull to the same server
    • The key has full read/write access to the repository
    • Deploy keys are usually not protected by a passphrase, making the key easily accessible if the server is compromised

    The other approach is to use the Credentials Jenkins plugin (initialized in February 2012), which allows to store credentials in Jenkins master.

    A single point for managing each credential. Change it in one place and you are done.

    As of version 1.5, the plugin now supports categorizing credentials into different “domains” in order to allow plugins to restrict the choice of credentials to only those that are appropriate.

    When a plugin is asking for a list of credentials, it can add some specifications about where and how the credential will be used.

    Example of Credential Domain configuration:

    This is fixed in recent Jenkins releases by centralizing credentials on master.

    Git Baby is a git and github fan, let's start git clone.