Category: git

Getting Jenkins to deploy with ansible using SSH Agent Forwarding

Your CI/CD tool needs access to code and server, for linting, testing and deploying.
Setup up access on the various devices in a secure manner can be very time consuming. It is important to make use of available technology to make our lives easier.

Jenkins needs access

You will have created credentials for Jenkins - by creating a SSH key pair for your jenkins user. Ensure that that public key have access to the code on your version control platform (as a deploy key).

Now jenkins will be able to get your code and run various tests on it. The problem now is deployment.


Use Jenkins's SSH credentials to Deploy

We are using ansible to deploy (from the jenkins box). So now jenkins needs access to wherever you are deploying the code to. You would do an ssh-copy-id to get it there.

But there is another problem, when ansible runs the git module to clone the repo you will get an error that the user does not have access.

Correct, the user on the box you are deploying to does not have access to the code. Now you could add that box as another deploy key but now when scaling out to many boxes you will have a hell of alot of ssh credentials to manage.

The best thing to do is use the jenkins user's cerentials that log into your target box to get the code. This is done with SSH Agent forwarding.

The first thing we will need is the  jenkins SSH agent plugin.

Then enable the SSH agent for your job:



Then install the Jenkins ansible plugin and configure it.

Finally you need to tell ansible to use SSH Agent forwarding, otherwise it just won't do it:

mkdir /etc/ansible
vi /etc/ansiible/ansible.cfg

Add the following config there:

host_key_checking = False

ssh_args = -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s

Of course, it is better to ensure host_key_checking is done.

Now everything should work.

Source: SSH Agent Forwarding with Ansible

Git Tutorial Part 3: Ignoring Files (Gitignore)

Git Ignoring Files

In most projects we have a set of files that we do not want to track these are usually logs or compilation or runtime files. In these cases we make use of:


To create a file listing to match the files we don't want to track:

cat .gitignore

This tells git to ignore all files ending in .o or .a and all files that end with a tilde.

It s important to setup your .gitignore before you get going on the project so you don't accidentally commit unnecessary files.

Gitignore Rules:

  • # : are comments
  • standard glob patterns work
  • Patterns ending in forward slash (/) specify a directory
  • You can negate a pattern by starting it with an exclamation point

Gitignore Manual Notes

 man git

Gitignore: specifies intentionally untracked files to ignore.


Files already tracked by git are not affected. Each gitignore file has a pattern, and have an order of precedence as follows:

  • Patterns read from command line
  • Patterns read from .gitignore in the same directory path and up, with those on a higher level of the directory tree being overridden by those below.
  • Patterns read from $GIT_DIR/info/exclude
  • Patterns read from the file specified by the config variable core.excludesfile.

Gitignore patterns should be version controlled and distributed to other repositories in the .gitignore file. Patterns specific to a single user should go into the $GIT_DIR/info/exclude file.

Files / patterns that should be ignored in all situations should go into the core.excludesfile in ~/.gitconfig

Pattern Format
  •  Blank lines serve as seperators for readability
  • A line starting with # is a comment
  • '!' negates the pattern
  • Pattern ending in a slash '/' will match a directory and those under it. Will not match a regulat file or symbolic link.
  • If the patterns does not contain a slash '/' git treats it as glob patterns
  • If the patterns does contain a slash '/' it is still treated as glob patterns
  • A leading slash matches files in the root directory
 Important Gitignore Notes

To ignore uncommited changes in a file that is already tracked:

git update-index --assume-unchanged

To stop tracking a file that is currently tracked:

git rm --cached

Taken from: Git Pro

Git Tutorial Part 2: Repository, Cloning, Tracking and Staging

This article gives the basics for a beginner user who needs to start tracking and contributing to projects managed with git.

The Git Repository

Initialising from an existing directory
git init

This command creates the .git directory.At this point nothing is tracked though.

git add *
git add README
git commit -m 'Initial Commit'
Cloning an Existing Repository

Cloning pulls an existing repo from a remote location to your local machine. This is usually the case when you want to contribute to an open source project. Remember the entire history is cloned. The latest copy of the project is checked our into the working directory.

git clone yiimod

The above command clones the yii framework into a folder called yiimod in the current directory.

Recording Changes

Each file in your working directory is of a certain state: tracked or untracked.

Tracked Files: In previous repo snapshot as unmodified, modified or staged.

Untracked Files: Files not in last snapshot and not in staging area.

When you first clone a directory all files will be tracked and unmodified. When files are edited they become modified, they are staged and then commited.

Checking File Statii

git status

This command tells you what branch you are on and the statii of files.

Adding a new file to the repo will give a response of:

 untracked files:

If you want to start tracking the newly added file you must explicitly:

git add <new file>

You must explicitly do so as it is possible that you application during compilation or runtime, additional unnecessary files were created.

Once you have added the file it is now staged as git status will give:

Changes to be commited:

If you modify a tracked file, without adding git status gives:

Changes not staged for commit:

This means the file is tracked and modified but not staged. If you add the modified file, the new file and modified file will show up under:

Changes to be commited:
new file: <new file>
modified: <modified file>

If you modify the <modified file> again, after git add, it will show up under both staged and unstaged changes. You will need to stage those unstaged changes.

Taken from: Pro Git