Posts Tagged ‘git’

cPanel now has support for deploying via git. Here is a quick guide on deploying PHP applications.

Upgrade Composer

The Composer version is old and will need an upgrade. To do this, you need to log into the server as root and run:

composer self-update

Install your SSH key

To avoid having to enter your password every time you push, log into cPanel and add your public SSH key. You can paste the id_rsa into the box and leave the name as default. Once added, go to the manage key and activate it.

Create a git repo

In cPanel, go into the git section and create a new repo. You can place it anywhere so perhaps a good place to put it is:

/home/username/git/repo-name

Add a remote

Back on your own computer, add the new cPanel repo as a remote.

git remote add cpanel ssh://username@example.com/home/username/git/repo-name

Add a cPanel config file

If you need to run any additional tasks, add a .cpanel.yml file to the root of your repo.

deployment:
  tasks:
    - composer install
    - /bin/cp -a /home/username/git/repo-name/public /home/username/public_html

5. Add a .cpanel.yml script

Push your code

Do a standard git push to deploy.

git push cpanel master

You can find the logs in /home/username/.cpanel/logs/ to find out if everything went as planned.

You may find that all the images you commit to a git repo are corrupting. This is especially true if you are using Windows and then pushing to a Linux origin.

One possible fix is to ensure the images are being treated as binary files. Of course everything is a binary file when it comes down to it, but this differentiates it from text. To do this, add the following lines to a .gitattributes file in the root of the repo.

*.jpg binary
*.png binary
*.gif binary

If you have images in there already, you will probably need to remove them and then re-commit them.

Hooks are scripts that you can use to run additional code when running Git commands. They are not stored in the repository so need to be set up on each computer individually.

You can create templates for your hooks that will be used whenever you create a new repository. To do this, put your scripts into the template folders on your local machine.

On Linux:

/usr/share/git-core/templates

On Windows:

Program Files (x86)\Git\share\git-core\templates

When you next run git init you will then have these templates installed by default. Additionally, you can run git init in existing repositories to update the templates (it will not do any damage to the repo itself).

These days cPanel comes with Git. However, it is not available as a command by default but is instead hidden away in cPanel’s usual obscure location.

However, you can make it accessible using a symlink.

ln -s /usr/local/cpanel/3rdparty/bin/git /usr/local/bin/git

That will allow you to use the git command as normal. The version you get is likely to behind the current version of Git though.

There are quite a number of tools to convert a CVS repository to a Git repository out there. However, most of them don’t seem to be able to copy over the branches properly. A work around is to convert it to Mercurial first, then convert it to Git.

In this example I’m using a repository called RedDog.

First, we need to get Mercurial on the system.

yum install mercurial

Next we need to add the convert extension to the .hrc file. This might be a global file, or might be in your home directory, can’t quite remember.

[extensions]
hgext.convert=

Check out from CVS and convert to Mercurial.

cvs checkout RedDog
hg convert RedDog

This will create a Mercurial repository called RedDog-hg. Now we need to get hold of Fast Export.

git clone git://repo.or.cz/fast-export.git

Once we have the software we can initialise a new Git repository that we’re going to use and then CD into the folder.

git init RedDog-git
cd RedDog-git

Run the Fast Export tool, specifying the location of the Mercurial repository.

../fast-export/hg-fast-export.sh -r ../RedDog-hg

This will migrate everything into your new Git repository. If you run an ls -a you should see the .git folder, which you may want to rename to RedDog.git (something.git locations are actually just .git directories).

You may optionally also want to do a check out into that folder.

git checkout HEAD

However, you don’t have to – you can begin using it remotely without doing a local checkout.

If you’re using version control (you are using version control, right?), the question sometimes comes up as to how often you should commit.

I’m a commit fanatic, I like to commit as soon as soon as I can, no matter how small the change. Other people prefer to wait a little and make large commits all at once. However often you choose to commit, you should make sure it falls within the constraint of being atomic.

This means that each commit is one single, complete change. That is to say that you shouldn’t commit multiple changes at once, nor should you commit a change that is only half done. This is scope in this for different approaches of course “one single, complete change” could be part of a several step refactor as long as the changes stand on their own, so could committing the refactor at once if it is all part of the same unit of work. But the important thing either way is to try and stick to atomic commits.

Think of it like an ACID transaction. Presumably you’re system works before you make the commit and it should work after too. It should contain just one feature so that if you want to roll that specific feature back, you can roll back that one commit without rolling anything else back.

With Git, where people may want to take out of sequence commits, this becomes especially important. People may want to take one of your changes, but not the other, so making sure two changes are in two separate commits is very important. Generally, if your descriptive commit comment (you are writing descriptive comments, right?) contains the word and, you probably need to re-think your commit.

Last week, I finally made it down to the Leeds PHP User Group.

The meeting consisted of a talk by Lorna Mitchell on Git, Github and Open Source. It didn’t tell me anything that I didn’t already know, but it was interesting none the less. They also provide free food at their meetings, so I then regretted eating before I went 😀 .

By a perhaps unfortunate coincidence, the next day one of my friends sent me a contact they recommend I speak to about my career. The name rang a bell – turns out the recruitment agency had in fact been sponsoring the event and she was there – if only I had known 24 hours earlier I could have introduced myself in person! Still, there is always next month.

Following on from my previous post about installing Git on CentOS 4, CentOS 5 is a whole different story. This is because you actually can get the RPM for Git on Cent OS – but cPanel doesn’t make it quite easy enough to do it.

You see, cPanel likes to take control of a lot of it’s own stuff, so it has a long list of packages which it won’t update automatically, because it will end up breaking itself if it does. As Git has two dependencies from the Perl libraries, this causes a problem.

But we can easily fix that.

cd /etc/
vim yum.conf

Remove perl* from the exclude line, then save the file. Now you should be able to run the command.

yum install git

It will gather all the dependencies and install Git. Final step, go back into the YUM configuration and put the exclude pack in to protect cPanel from its malevolent self.

vim yum.conf

If you’re trying to install Git on CentOS with cPanel, you’ll probably be running into the problems where you can’t get hold the RPM because cPanel excludes all Perl modules. But that is a whole different problem to if you are running CentOS 4.

CentOS 4 doesn’t actually have the RPMs for Git at all. But luckily, it’s actually really easy to install on a cPanel server because cPanel should come will all the dependencies you need.

So, all you need to do is head over to the Git website, download the latest source (I tried it with v1.7.8.1) and compile it – no problems, no worries.

wget http://git-core.googlecode.com/files/git-1.7.8.1.tar.gz
tar xvzf git-1.7.8.1.tar.gz
cd git-1.7.8.1
./configure
make
make install