Setup

The first real, working development pipeline for this blog used the GitHub to FTP approach. Before that, I tried a somewhat convoluted version of the “Pull” approach the guide in the official cPanel docs, which outlines two basic options:

Push Method

cPanel Push Method Illustration

Edit your website on your computer, push the changes to a single Git repo in cPanel, and it will automatically update

  1. Use cPanel’s Git Version Control tool to make an empty repository
  2. Clone that to your computer
  3. Use a .cpanel.yml file to tell cPanel to deploy the files from the repo to your production website

Pull Method

cPanel Pull Method Illustration

Edit your website files on your computer, push changes to the first repository (probably on GitHub), then manually tell your secondary cPanel Git repo to pull those changes and deploy them to the live website

  1. Start with some other repo that you want to use
  2. Clone that to your computer
  3. Push changes to the secondary cPanel repo
  4. Click on “Update from Remote” and “Deploy HEAD commit” in the cPanel GUI

My method…

…turned out to be redundant and overly complicated, for a few reasons.

  1. Create a private GitHub repository
  2. Setup SSH access so cPanel’s repo had permission to snag the website files from GitHub
  3. Create a .cpanel.yml file, but also setup up the Pull method, so I had to get into cPanel and manually deploy changes, anyway

Why did it work out like that?

  • I conflated Git with GitHub. Git is a platform-agnostic system that companies like GitHub and cPanel use. When I was reading the docs and tutorials, it was easy to forget about that. I didn’t need both for the recommended Push method

GitHub vs Git Illustration

  • I wanted to use a private repo and set up SSH access. That was just for practice, since this is a home lab project, after all. But it made things needlessly complex

Process / Hurdles

“/usr/local/cpanel/3rdparty/bin/git” reported error code “128”

128 Error in cPanel Illustration

“ERROR: You’re using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.”

ssh-keygen -t ecdsa -b 521

“fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.”

eval `ssh-agent -s`
ssh-add ../.ssh/RSAkey

“You’ve successfully authenticated, but GitHub does not provide shell access.”

ssh -i ~/.ssh/repo -T git@example.com
  • NOTE: In the command above, you do need to use the path and key name specific to your project when you set them up. BUT, you literally enter “git@github.com”, assuming you are using GitHub as the platform for the remote repo
  • This message actually means you added the SSH key correctly. But you’ll just be using it to securely clone a repo, not gain remote access to GitHub
  • You’ve successfully authenticated, but GitHub does not provide shell access. · community · Discussion #33982
  • After getting these errors out of the way, I was able to clone my private GitHub repo into my secondary cPanel Git repo

Takeaways

Public vs Private Repo

  • All of this is only necessitated by having a private repo
    • Anyone can clone a public repo
    • You can clone your own private repo
    • But GitHub doesn’t know your web server is you without signing in
  • Instead of just signing in with a username/password, you authenticate with an SSH private/public key pair
    • You can generate the key in the shell or through the cPanel plugin, makes no difference
    • Just remember to activate it
    • Then copy the public key over to GitHub as an SSH or Deploy key

GitHub SSH key vs Deploy key

GitHub Illustration of adding a Deploy key

Future Improvements

Sources