Posts Tagged ‘git’

Deploying to cPanel using git

Monday, February 15th, 2021 | Programming

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.

Atomic commits

Thursday, August 9th, 2012 | Limited, Programming

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.

Leeds PHP User Group

Friday, March 30th, 2012 | Life, Tech

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.