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.

  • How to create development branch from master on GitHub
  • How do I prevent git push <branch> from pushing unless I am checked out on that branch?
  • Making commits simpler in Git using PowerShell
  • Reverting a broken merge and reapplying selected commits with Git
  • Git: discover which commits ever touched a range of lines
  • git: list all files added/modified on a day (or week/month…)
  • I hope someone know a way to achieve this because setting up GitHub publickeys for every slave sounds ridiculous.

  • How do I use Git's interactive rebase with a local-only repository (no remote / origin)?
  • having trouble during initial build for project “gameoflife” when following “jenkins the definitive guide” by john ferguson
  • Get git current branch/tag name
  • git: using object shas in a pre-commit hook
  • How to revert multiple commits as part of a single commit
  • How to separate local from shared code using git repos
  • 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.

    Pros

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

    Cons

    • 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:

    https://wiki.jenkins-ci.org/download/attachments/59511751/Screen+Shot+2013-08-07+at+13.50.42.png?version=1&modificationDate=1375880556000

    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.