It'd be nice to have Native Trac and SVN support. Don't ya think?
Original thread: http://forums.cpanel.net/f145/version-control-system-integration-179051.html
Allow users to install websites from version control
Completed
Just a small feature request we think would be useful for clients utilizing web files that get version controlled through svn, git or mercurial.
Our proposed implementation would be to have a VC control tools (ie a GIT button) in the File Manager that allows users to pull/push/checkout/checkin repositories to the directory they choose, and keep it updated.
The current method is to download the zip from git and upload it via the file manager, over-writing files as it goes however we propose the VC method to allow users to roll back after a failed deployment.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
Hey folks! This feature was added to cPanel & WHM in Version 72, which is available in the CURRENT tier now! Take a look at the release notes, and see all of the highlights for this version on the 72 Release Site.
https://documentation.cpanel.net/display/72Docs/72+Release+Notes#id-72ReleaseNotes-NewGit%E2%84%A2VersionControlfeature
Hey folks! This feature was added to cPanel & WHM in Version 72, which is available in the CURRENT tier now! Take a look at the release notes, and see all of the highlights for this version on the 72 Release Site.
https://documentation.cpanel.net/display/72Docs/72+Release+Notes#id-72ReleaseNotes-NewGit%E2%84%A2VersionControlfeature
Very interesting. How would you expect database migrations (upgrades to the schema, etc) or cache flushes to be handled?
Very interesting. How would you expect database migrations (upgrades to the schema, etc) or cache flushes to be handled?
This is a feature that I personally feel is extremely valuable to our more technical users, as this is how modern developers interact with code and push code around. When looking the ability to deploy from version control I can see quite a few advantages and disadvantages. When discussing this feature I will use 'git' however that does not mean we are unwilling to look into mercurial or svn support.
I do feel that just building this into the file manager, while possibly a great minimum viable product for this feature, is not harnessing the entire power of git for this feature.
Below are some of the various use cases that I have come up with while grokking this feature:
The usual feedback I hear on this is that this is too technical of a feature for use by your average cPanel user.
This is a feature that I personally feel is extremely valuable to our more technical users, as this is how modern developers interact with code and push code around. When looking the ability to deploy from version control I can see quite a few advantages and disadvantages. When discussing this feature I will use 'git' however that does not mean we are unwilling to look into mercurial or svn support.
I do feel that just building this into the file manager, while possibly a great minimum viable product for this feature, is not harnessing the entire power of git for this feature.
Below are some of the various use cases that I have come up with while grokking this feature:
The usual feedback I hear on this is that this is too technical of a feature for use by your average cPanel user.
I would better encourage some version controlling system (both remote and on server) so any changes under specific repository over a specific branch can be used for this.
I personally don't feel the cPanel will be interested as this feature involves moderator controls and understanding however for cPanel, I would love to see this as simple as it can i.e. some options where user can change his mode to developer mode and than all such settings may start appearing.
Anyways, I am strongly supporting this feature as in many cases with me, I have to alter system configurations and have to provide shell access to my clients requiring this feature with cpanel which makes the system unstable farmost time.
I would better encourage some version controlling system (both remote and on server) so any changes under specific repository over a specific branch can be used for this.
I personally don't feel the cPanel will be interested as this feature involves moderator controls and understanding however for cPanel, I would love to see this as simple as it can i.e. some options where user can change his mode to developer mode and than all such settings may start appearing.
Anyways, I am strongly supporting this feature as in many cases with me, I have to alter system configurations and have to provide shell access to my clients requiring this feature with cpanel which makes the system unstable farmost time.
Honestly, this feature is not necessary. There are more important features that cPanel needs to focus their time on than something the "more technical users" as one puts it, can simply setup themselves. SNV is just about obsolete, and who uses Mercurial? Git is what most everyone uses, and the ones that don't, should.
BUT... What would be nice is if cPanel installed Git by default with itself, like it does everything else, that way developers working on cPanel servers that don't have root access can setup Git repos per project/user.
IF... you do have root access, it is fairly simple to setup Git on cPanel servers. I currently am and have been using Git for my projects for some time now on cPanel servers with no issues. The setup isn't much different, just requires a few extra steps to get it working the "cPanel" way.
As Root:
1. Verify that the /etc/yum.conf file does not contain perl* in the exclude line.
2. yum install git
3. nano /opt/suphp/etc/suphp.conf
change: allow_file_group_writeable=true
change: allow_directory_group_writeable=true
As User: (not root, or you will run into all kinds of permission errors)
1. Enable shell access for user account - Jailed Shell or Normal Shell (Doesn't matter, they both work)
2. Login As User, and setup your repo...
I personally like to initialize my repo before the public_html directory, and follow the cPanel structure in my repo for better compatibility with cPanel severs. But, everyone has their own weird way of doing things, so do whatever makes the most sense to you.
My Way example:
SSH to /home/some-user-account
Type: git init
Type: git config --global user.name "FirstName LastName"
Type: git config --global user.email "youremail.com"
Type: git config --global core.excludesfile ~/.gitignore
Type: git remote add origin https://somerepo.git
/home/some-user-account/.gitignore: (ignore everything but public_html directory)
This .gitignore file is basically for cpanel stuff, you can add another to the public_html directory to ignore project files. Git supports multiple .gitignore files and can be placed just about anywhere. They work the same exact way robots.txt files do. So if you want Git to ignore for example, your cache folders and all xml files, just create another .gitignore file and place it inside your public_html directory.
Anytime you want to deploy, just login as user and type: git pull origin master (or whatever branch u want to pull).
Honestly, this feature is not necessary. There are more important features that cPanel needs to focus their time on than something the "more technical users" as one puts it, can simply setup themselves. SNV is just about obsolete, and who uses Mercurial? Git is what most everyone uses, and the ones that don't, should.
BUT... What would be nice is if cPanel installed Git by default with itself, like it does everything else, that way developers working on cPanel servers that don't have root access can setup Git repos per project/user.
IF... you do have root access, it is fairly simple to setup Git on cPanel servers. I currently am and have been using Git for my projects for some time now on cPanel servers with no issues. The setup isn't much different, just requires a few extra steps to get it working the "cPanel" way.
As Root:
1. Verify that the /etc/yum.conf file does not contain perl* in the exclude line.
2. yum install git
3. nano /opt/suphp/etc/suphp.conf
change: allow_file_group_writeable=true
change: allow_directory_group_writeable=true
As User: (not root, or you will run into all kinds of permission errors)
1. Enable shell access for user account - Jailed Shell or Normal Shell (Doesn't matter, they both work)
2. Login As User, and setup your repo...
I personally like to initialize my repo before the public_html directory, and follow the cPanel structure in my repo for better compatibility with cPanel severs. But, everyone has their own weird way of doing things, so do whatever makes the most sense to you.
My Way example:
SSH to /home/some-user-account
Type: git init
Type: git config --global user.name "FirstName LastName"
Type: git config --global user.email "youremail.com"
Type: git config --global core.excludesfile ~/.gitignore
Type: git remote add origin https://somerepo.git
/home/some-user-account/.gitignore: (ignore everything but public_html directory)
This .gitignore file is basically for cpanel stuff, you can add another to the public_html directory to ignore project files. Git supports multiple .gitignore files and can be placed just about anywhere. They work the same exact way robots.txt files do. So if you want Git to ignore for example, your cache folders and all xml files, just create another .gitignore file and place it inside your public_html directory.
Anytime you want to deploy, just login as user and type: git pull origin master (or whatever branch u want to pull).
While highly technical in nature, this idea has potential for end-users if it's executed properly. The idea of designers providing a GIT repo URL to customers...and all the customer has to do is register it within cPanel and hit deploy...that has sexy written all over it.
While highly technical in nature, this idea has potential for end-users if it's executed properly. The idea of designers providing a GIT repo URL to customers...and all the customer has to do is register it within cPanel and hit deploy...that has sexy written all over it.
I'm really curious about this feature. Some of my customers have been asking for this as they are mostly designers and do not have a lot of experience using SSH. Any comments on the status?
I'm really curious about this feature. Some of my customers have been asking for this as they are mostly designers and do not have a lot of experience using SSH. Any comments on the status?
We haven't considered adding this to the roadmap since I started in this position in March, but I can definitely bring it up again. With only 17 votes over nearly a year, it doesn't seem like this has much interest in the community.
We haven't considered adding this to the roadmap since I started in this position in March, but I can definitely bring it up again. With only 17 votes over nearly a year, it doesn't seem like this has much interest in the community.
I have to use cPanel for clients on a regular basis and I find this extremely frustrating, so much so that I ended up using Plesk instead which has GIT control baked in and can be set up in about 3 clicks. Now I just use subdomains with protected directories that are all set up to automatically pull any changes from GitHub and everything works seamlessly - clients can see me update things in real time.
To confirm cPanelAdamF's statement: It is absolutely sexy.
I have to use cPanel for clients on a regular basis and I find this extremely frustrating, so much so that I ended up using Plesk instead which has GIT control baked in and can be set up in about 3 clicks. Now I just use subdomains with protected directories that are all set up to automatically pull any changes from GitHub and everything works seamlessly - clients can see me update things in real time.
To confirm cPanelAdamF's statement: It is absolutely sexy.
Staging / Development / Production sites with GIT through cPanel. That'd be awesome :)
Staging / Development / Production sites with GIT through cPanel. That'd be awesome :)
My team and I just had a serious discussion about this with intent to start planning it out. I'll have more to say after we explore the idea more...including a call for focus group members...when we get done with that exploration.
We're excited!
My team and I just had a serious discussion about this with intent to start planning it out. I'll have more to say after we explore the idea more...including a call for focus group members...when we get done with that exploration.
We're excited!
Good news!!
A nice feature I like in other services is the ability to configure a webhook (for example at github) so that a pull is triggered whenever a new version is pushed on the master branch.
Good news!!
A nice feature I like in other services is the ability to configure a webhook (for example at github) so that a pull is triggered whenever a new version is pushed on the master branch.
This is now officially planned for v68, baring unforeseen circumstances!
This is now officially planned for v68, baring unforeseen circumstances!
A lot of this is already do-able in v64 and newer. We're prepping some documentation for advanced users comfortable at the command line that will describe the way to achieve it right now.
Don't worry. Still building out a nice new feature in the cpanel interface for it too ;-)
A lot of this is already do-able in v64 and newer. We're prepping some documentation for advanced users comfortable at the command line that will describe the way to achieve it right now.
Don't worry. Still building out a nice new feature in the cpanel interface for it too ;-)
New documentation for how to do it right now (v64 or newer) is now available.
https://documentation.cpanel.net/display/CKB/How+to+Host+Git+Repositories+on+a+cPanel+Account
As a result of working up this doc, the team and I identified three major scenarios that we need to plan for in the development of this feature:
I've got those roughly ordered in terms of complexity. 1 and 2 are already possible right now, and the new document explains how to do it via command-line. 3 is where the fun is ;-)
New documentation for how to do it right now (v64 or newer) is now available.
https://documentation.cpanel.net/display/CKB/How+to+Host+Git+Repositories+on+a+cPanel+Account
As a result of working up this doc, the team and I identified three major scenarios that we need to plan for in the development of this feature:
I've got those roughly ordered in terms of complexity. 1 and 2 are already possible right now, and the new document explains how to do it via command-line. 3 is where the fun is ;-)
Question for the room: How do you plan on marketing this feature? What would advertisements on your hosting company's website look like for this?
I ask because this will help guide us in how best to chop up this feature's capabilities and how best to schedule out which parts of the project we do first.
Question for the room: How do you plan on marketing this feature? What would advertisements on your hosting company's website look like for this?
I ask because this will help guide us in how best to chop up this feature's capabilities and how best to schedule out which parts of the project we do first.
Dev update for everyone:
We've broken ground on the interfaces to create and list git repositories. I'll have some early screenshots to share here pretty soon.
We did identify a couple of things now that we're getting started.
First, we know people will create git repositories from the shell since they have that ability so we're going to implement a 'discover repositories' button which will trigger a scan of the user's home directory for .git folders and update the list of repositories in the interface. (Pushing it more than once in rapid succession will only trigger one scan for that user at one time. Scanning file structures is slow and expensive so we're building it in such a way that it can't really be abused.)
Second, we've discussed performing a 'git stash --include-untracked' before receiving any git-push in order to clear out any local changes that might exist on the cpanel-remote. In the occasion where we end up git-stashing something, we'll shoot a note to the end-user saying "hey, we cleaned up something in order to perform your deployment. Here's the git-stash-apply command to restore it". What do you all think of this idea? Should we simply fail the deployment instead?
Dev update for everyone:
We've broken ground on the interfaces to create and list git repositories. I'll have some early screenshots to share here pretty soon.
We did identify a couple of things now that we're getting started.
First, we know people will create git repositories from the shell since they have that ability so we're going to implement a 'discover repositories' button which will trigger a scan of the user's home directory for .git folders and update the list of repositories in the interface. (Pushing it more than once in rapid succession will only trigger one scan for that user at one time. Scanning file structures is slow and expensive so we're building it in such a way that it can't really be abused.)
Second, we've discussed performing a 'git stash --include-untracked' before receiving any git-push in order to clear out any local changes that might exist on the cpanel-remote. In the occasion where we end up git-stashing something, we'll shoot a note to the end-user saying "hey, we cleaned up something in order to perform your deployment. Here's the git-stash-apply command to restore it". What do you all think of this idea? Should we simply fail the deployment instead?
Short back-end updates for everyone:
I'm hoping to have a public 'not even EDGE yet' build available for everyone to play with by the end of next week. (Don't hold me to that, lots can happen between now and then which might delay it). Such a build will have the new feature available in cPanel and provide the means to create and list git repositories as well as discover repositories that were created outside of the feature.
Short back-end updates for everyone:
I'm hoping to have a public 'not even EDGE yet' build available for everyone to play with by the end of next week. (Don't hold me to that, lots can happen between now and then which might delay it). Such a build will have the new feature available in cPanel and provide the means to create and list git repositories as well as discover repositories that were created outside of the feature.
Update on the release of a 'not even edge yet' build: not happening this week due to having to delay for the targeted security release we issued earlier this week, as well as putting some finishing touches on the creating and listing repositories portions of the feature. We want to include showing the "clone-able" URLs after you create a repository in the first preview release of it so that you can see the whole "create => clone => push/pull" lifecycle.
I'll set the new expectation to middle of next week and I'll have more details about what's in that preview release later on.
Update on the release of a 'not even edge yet' build: not happening this week due to having to delay for the targeted security release we issued earlier this week, as well as putting some finishing touches on the creating and listing repositories portions of the feature. We want to include showing the "clone-able" URLs after you create a repository in the first preview release of it so that you can see the whole "create => clone => push/pull" lifecycle.
I'll set the new expectation to middle of next week and I'll have more details about what's in that preview release later on.
Alright, here we go. The first incremental delivery of the feature is about to go into our upstream and be built for release in a "not even edge yet" build. Here's a brief about what it can currently do and some known issues to keep in mind:
Feature index page
Repository Creation screen
Some known issues:
I"ll have build information available for everyone once the merge and build process finishes up.
Next up, we dive head-long into the deployment related scope of the project!
Alright, here we go. The first incremental delivery of the feature is about to go into our upstream and be built for release in a "not even edge yet" build. Here's a brief about what it can currently do and some known issues to keep in mind:
Feature index page
Repository Creation screen
Some known issues:
I"ll have build information available for everyone once the merge and build process finishes up.
Next up, we dive head-long into the deployment related scope of the project!
For those interested in installing a "not even edge yet" build and playing with this feature, please hit me up! adam.french@cpanel.net - I've got to send you install instructions!
For those interested in installing a "not even edge yet" build and playing with this feature, please hit me up! adam.french@cpanel.net - I've got to send you install instructions!
We were actually able to get the "clone from external repo" stable for this "not even edge yet" build as well. Here's an updated screenshot of the create page now:
Known Issues:
We were actually able to get the "clone from external repo" stable for this "not even edge yet" build as well. Here's an updated screenshot of the create page now:
Known Issues:
Small update for everyone - our release team is updating git to 2.14.0 in the "not even edge yet" builds. If you're curious what's new between 2.13 and 2.14: https://github.com/git/git/blob/master/Documentation/RelNotes/2.14.0.txt - Doesn't really have much of an effect for our particular project, but figured I'd FYI anyway.
Small update for everyone - our release team is updating git to 2.14.0 in the "not even edge yet" builds. If you're curious what's new between 2.13 and 2.14: https://github.com/git/git/blob/master/Documentation/RelNotes/2.14.0.txt - Doesn't really have much of an effect for our particular project, but figured I'd FYI anyway.
Alright so we're coming up on a release deadline internally so I have to make some hard decisions about what makes it into v68 and what waits until the next release.
Right now, the feature provides for...
As far as I can tell, that's what you can expect in the v68 version of this feature. I know many of you were looking forward to the deployment tasks portion of the scope as well as the "make it work under noshell" support but it looks like that's about as far as we can get for v68 and still have time to stabilize and fight bugs without introducing new ones.
The good news, though, is that this isn't the end of this feature's development. I've gotten go-ahead to continue work on this feature for at least another release after the holidays are over. The leadership of cPanel product development feel as strongly as you do on the potential for version control integration inside cPanel & WHM AND I can tell you from personal experience that my team and I ADORE working on this project. (Git is so freakin' cool when you pop the hood and have a good look.)
In another update, I'll post our thinking as far as what's next on our TODO list for the project. It would be incredibly helpful to get everyone's opinion on what's most important, and what can wait until later, for the next update to this feature!
Alright so we're coming up on a release deadline internally so I have to make some hard decisions about what makes it into v68 and what waits until the next release.
Right now, the feature provides for...
As far as I can tell, that's what you can expect in the v68 version of this feature. I know many of you were looking forward to the deployment tasks portion of the scope as well as the "make it work under noshell" support but it looks like that's about as far as we can get for v68 and still have time to stabilize and fight bugs without introducing new ones.
The good news, though, is that this isn't the end of this feature's development. I've gotten go-ahead to continue work on this feature for at least another release after the holidays are over. The leadership of cPanel product development feel as strongly as you do on the potential for version control integration inside cPanel & WHM AND I can tell you from personal experience that my team and I ADORE working on this project. (Git is so freakin' cool when you pop the hood and have a good look.)
In another update, I'll post our thinking as far as what's next on our TODO list for the project. It would be incredibly helpful to get everyone's opinion on what's most important, and what can wait until later, for the next update to this feature!
We'll be updating the feature in the upcoming EDGE push of v68 soon. When we do, that'll be the debut of the new deployment set of features I've described previously.
We need your help and evaluation notes for that work to make sure we're meeting your expectations!
I do have some rather technical notes to share with regard to how we did it so that you understand some of the design decisions we've had to make. Here goes:
Git repositories take up space
All files hosted in a user's home directory are counted against any disk usage quota. This includes the ".git" directories of any git repositories they create. Keep this in mind when you're designing your web hosting packages for your customers. Git repositories can grow pretty quickly depending on end-user activity.
Deployment means "deploy right now"
When deployment is enabled, the net effect is that any new commits that arrive to the deployed branch get deployed RIGHT NOW. There are two scenarios to consider here:
First, if the cpanel-hosted repository is playing the classical git convention of a "origin repository", the end-user is performing a 'git push' in order to push changes up to it. When that git-push happens, any changes to the branch configured as the deployment branch will be deployed RIGHT NOW. No delay. If something in the cpanel-hosted repository working-tree conflicts with something in their push, the push will fail and they'll be told about it. It's an atomic transaction so there's no such thing as a "partially successful push" (thank you, git, for being awesome like that).
Second, if the cpanel-hosted repository is a "clone" of a remote repository elsewhere (like if the code is on github and they want it deployed to their cpanel account), new changes will arrive via a 'git fetch' and 'git pull'. You'll only see available branches from the REMOTE repository when you go to choose a branch to deploy. This is intentional as we want to treat the cpanel-hosted repository as much like a mirror of the remotely hosted repo as possible.
When new changes are 'git pull'-ed into the cpanel-hosted repo, we will only perform the deployment if it can be 'fast-forwarded' into place. This is to, again, avoid any local changes to the cpanel-hosted repository that could eventually diverge from the remotely hosted repository.
Remember: you can push/pull to your hearts content to any branch OTHER than the deployed branch at any time. We pretty much ignore everything that happens to your repo beyond changes on the deployed branch.
Use git submodules? We got you fam.
All of the git operations cPanel performs on your repositories are submodule aware. Want to clone a remotely hosted repository onto your cpanel account? If it has submodules, those get cloned and initialized too. Was there new changes upstream on a submodule you're using? Just trigger a deployment and the git commands we apply to your repository will recursively retrieve any new changes for your submodules.
Enabling deployment on a bare repository means we have to convert it into a non-bare one
This is just a housekeeping thing. If you create a 'bare' repository...and then later on decide to enable deployment on it...cPanel will happily convert it into a 'non-bare' repository for you. This involves temporarily moving your repository out of the way and then relocating its contents into a .git/ folder inside folder at your repositories previous location...and then perform a checkout of the most recent change on your deployment branch.
"But Adam, doesn't this mess up my clone URLs if I have that repository cloned locally?" you ask. Nope, it doesn't. Git has some magic in place that handles this cleanly. You won't have to update your git-remotes locally because it'll find what it needs at the URL provided just fine. Git's kinda neat that way ;-)
Deleting a repo means sending it to the trash
So you can create and deploy git repositories all you want now, but what about deleting it? When you delete a repository, cPanel will move the git repository AND its working tree contents into your "~/.trash" directory for the trash system to purge. Depending on your settings in "WHM » Tweak Settings", the "~/.trash" folder will get purged instantly or on a regular schedule for your end-users.
If you need to recover a git repository for an end-user, definitely check their "~/.trash" directory first. Hitting the magic 'Restore' button in File Manager sets everything back the way it was!
Don't muck about in a .git folder
So all of this git-foo is happening in the end-user's home directory...which means they're going to see the ".git" directory if they have "Show Hidden Files" enabled in File Manager. PLEASE discourage your end-users from mucking about in that directory because they can do some real damage to its integrity.
ALSO let us know about how frequently you see trouble tickets from your customers where they've gotten themselves confused about whatever-the-heck the ".git" directory is. If this happens often enough that it's causing you headaches, we'll re-evaluate our implementation and hide these further. We know end-users "fiddle" and get themselves into trouble and this could potentially be an avenue for that.
Ok so that's it for this update. Definitely hit me up in the replies with questions!
We'll be updating the feature in the upcoming EDGE push of v68 soon. When we do, that'll be the debut of the new deployment set of features I've described previously.
We need your help and evaluation notes for that work to make sure we're meeting your expectations!
I do have some rather technical notes to share with regard to how we did it so that you understand some of the design decisions we've had to make. Here goes:
Git repositories take up space
All files hosted in a user's home directory are counted against any disk usage quota. This includes the ".git" directories of any git repositories they create. Keep this in mind when you're designing your web hosting packages for your customers. Git repositories can grow pretty quickly depending on end-user activity.
Deployment means "deploy right now"
When deployment is enabled, the net effect is that any new commits that arrive to the deployed branch get deployed RIGHT NOW. There are two scenarios to consider here:
First, if the cpanel-hosted repository is playing the classical git convention of a "origin repository", the end-user is performing a 'git push' in order to push changes up to it. When that git-push happens, any changes to the branch configured as the deployment branch will be deployed RIGHT NOW. No delay. If something in the cpanel-hosted repository working-tree conflicts with something in their push, the push will fail and they'll be told about it. It's an atomic transaction so there's no such thing as a "partially successful push" (thank you, git, for being awesome like that).
Second, if the cpanel-hosted repository is a "clone" of a remote repository elsewhere (like if the code is on github and they want it deployed to their cpanel account), new changes will arrive via a 'git fetch' and 'git pull'. You'll only see available branches from the REMOTE repository when you go to choose a branch to deploy. This is intentional as we want to treat the cpanel-hosted repository as much like a mirror of the remotely hosted repo as possible.
When new changes are 'git pull'-ed into the cpanel-hosted repo, we will only perform the deployment if it can be 'fast-forwarded' into place. This is to, again, avoid any local changes to the cpanel-hosted repository that could eventually diverge from the remotely hosted repository.
Remember: you can push/pull to your hearts content to any branch OTHER than the deployed branch at any time. We pretty much ignore everything that happens to your repo beyond changes on the deployed branch.
Use git submodules? We got you fam.
All of the git operations cPanel performs on your repositories are submodule aware. Want to clone a remotely hosted repository onto your cpanel account? If it has submodules, those get cloned and initialized too. Was there new changes upstream on a submodule you're using? Just trigger a deployment and the git commands we apply to your repository will recursively retrieve any new changes for your submodules.
Enabling deployment on a bare repository means we have to convert it into a non-bare one
This is just a housekeeping thing. If you create a 'bare' repository...and then later on decide to enable deployment on it...cPanel will happily convert it into a 'non-bare' repository for you. This involves temporarily moving your repository out of the way and then relocating its contents into a .git/ folder inside folder at your repositories previous location...and then perform a checkout of the most recent change on your deployment branch.
"But Adam, doesn't this mess up my clone URLs if I have that repository cloned locally?" you ask. Nope, it doesn't. Git has some magic in place that handles this cleanly. You won't have to update your git-remotes locally because it'll find what it needs at the URL provided just fine. Git's kinda neat that way ;-)
Deleting a repo means sending it to the trash
So you can create and deploy git repositories all you want now, but what about deleting it? When you delete a repository, cPanel will move the git repository AND its working tree contents into your "~/.trash" directory for the trash system to purge. Depending on your settings in "WHM » Tweak Settings", the "~/.trash" folder will get purged instantly or on a regular schedule for your end-users.
If you need to recover a git repository for an end-user, definitely check their "~/.trash" directory first. Hitting the magic 'Restore' button in File Manager sets everything back the way it was!
Don't muck about in a .git folder
So all of this git-foo is happening in the end-user's home directory...which means they're going to see the ".git" directory if they have "Show Hidden Files" enabled in File Manager. PLEASE discourage your end-users from mucking about in that directory because they can do some real damage to its integrity.
ALSO let us know about how frequently you see trouble tickets from your customers where they've gotten themselves confused about whatever-the-heck the ".git" directory is. If this happens often enough that it's causing you headaches, we'll re-evaluate our implementation and hide these further. We know end-users "fiddle" and get themselves into trouble and this could potentially be an avenue for that.
Ok so that's it for this update. Definitely hit me up in the replies with questions!
Thanks very much for this fantastic looking feature! I do a lot of work with the flat-file CMS Grav using Git repositories to hold site content and the existing Git Sync Plugin to push/pull changes automatically.
I've been able to clone an existing Grav CMS site to my test cPanel server using the new Git Feature, but I cannot seem to request changes to either the local files or to the remote Git repository are synced - will this type of process be possible once the feature gets further developed? Please pardon my lack of technical knowledge, I am not a developer myself :-)
Thanks very much,
Paul
Thanks very much for this fantastic looking feature! I do a lot of work with the flat-file CMS Grav using Git repositories to hold site content and the existing Git Sync Plugin to push/pull changes automatically.
I've been able to clone an existing Grav CMS site to my test cPanel server using the new Git Feature, but I cannot seem to request changes to either the local files or to the remote Git repository are synced - will this type of process be possible once the feature gets further developed? Please pardon my lack of technical knowledge, I am not a developer myself :-)
Thanks very much,
Paul
So I would be remiss in my product manager duties if I didn't update you all on what's going on. Don't worry. Everything's fine!
At the end of last week, my team and I tidied up the remaining loose ends and submitted the deployment features to v68. As a result of the review process, one of our coworkers who had never played with the feature BUT uses git deployment for their current websites attempted to convert their setup to use the new Git Version Control and Deployment features.
While the feature worked just fine, a few of their repositories had git-remotes which either no longer existed or responded very slowly. As a result, a few of the Git Version Control and Deployment interfaces locked up waiting for the 'git fetch' commands to finish cleanly.
Not good. I'm glad we caught this before release! It would have resulted in your customers staring at blank screens for ages waiting for the interface to show up.
We're now making a few tweaks to the network code around retrieving changes from other repositories, as well as related API calls, to handle this situation better. We are updating the offending interfaces not to require so much information about each repository and to avoid network activity entirely wherever possible. There will be some visual changes to the interfaces I posted screenshots of earlier but hopefully just minor tweaks.
So that's what's going on. If you're interested in playing with the feature before it hits EDGE, definitely reach out to me here or shoot me a note at adam.french@cpanel.net. I'll need to send you beta installation instructions!
So I would be remiss in my product manager duties if I didn't update you all on what's going on. Don't worry. Everything's fine!
At the end of last week, my team and I tidied up the remaining loose ends and submitted the deployment features to v68. As a result of the review process, one of our coworkers who had never played with the feature BUT uses git deployment for their current websites attempted to convert their setup to use the new Git Version Control and Deployment features.
While the feature worked just fine, a few of their repositories had git-remotes which either no longer existed or responded very slowly. As a result, a few of the Git Version Control and Deployment interfaces locked up waiting for the 'git fetch' commands to finish cleanly.
Not good. I'm glad we caught this before release! It would have resulted in your customers staring at blank screens for ages waiting for the interface to show up.
We're now making a few tweaks to the network code around retrieving changes from other repositories, as well as related API calls, to handle this situation better. We are updating the offending interfaces not to require so much information about each repository and to avoid network activity entirely wherever possible. There will be some visual changes to the interfaces I posted screenshots of earlier but hopefully just minor tweaks.
So that's what's going on. If you're interested in playing with the feature before it hits EDGE, definitely reach out to me here or shoot me a note at adam.french@cpanel.net. I'll need to send you beta installation instructions!
oh, I forgot to mention, check out the new feature icon:
oh, I forgot to mention, check out the new feature icon:
Catch-up update for everyone now that our issues with the feature request site have been resolved. Here's where everything stands on the feature.
First off, this feature will debut in cPanel & WHM v72, slated for release very soon (after 70 makes it through our release schedule). The v72 release includes:
The feature will be enabled by default (which is our usual procedure), but you can control access to it using a new Feature Manager entry titled "Git Version Control". We've got considerable amounts of documentation prepped for this feature (our docs specialist, Sarah, deserves particular commendations for the heroics she's pulled for this feature) that will get published around the time of v72's release that'll expand (greatly) on my quick description here.
Ok so v74 is also very far along at this point as well. Once v72 is moving through our release schedule, I'll be able to share 'bleeding edge' builds of new deployment focused features!
Right now, v74's deployment focus consists of...
Soon we'll be turning our attention to improving management of SSH Keys. I'll have more conversation about that when plans enter the "ok, let's figure out specifics" phase of planning.
Catch-up update for everyone now that our issues with the feature request site have been resolved. Here's where everything stands on the feature.
First off, this feature will debut in cPanel & WHM v72, slated for release very soon (after 70 makes it through our release schedule). The v72 release includes:
The feature will be enabled by default (which is our usual procedure), but you can control access to it using a new Feature Manager entry titled "Git Version Control". We've got considerable amounts of documentation prepped for this feature (our docs specialist, Sarah, deserves particular commendations for the heroics she's pulled for this feature) that will get published around the time of v72's release that'll expand (greatly) on my quick description here.
Ok so v74 is also very far along at this point as well. Once v72 is moving through our release schedule, I'll be able to share 'bleeding edge' builds of new deployment focused features!
Right now, v74's deployment focus consists of...
Soon we'll be turning our attention to improving management of SSH Keys. I'll have more conversation about that when plans enter the "ok, let's figure out specifics" phase of planning.
I've been thinking about setting up some kind of GIT deployment system myself, so this is a great addition.
I've been thinking about setting up some kind of GIT deployment system myself, so this is a great addition.
For those interested, v72 (under the name of v71) is now available in the EDGE tier and has the feature available to play with. Now would be a great time to create an edge server and check it out!
For those interested, v72 (under the name of v71) is now available in the EDGE tier and has the feature available to play with. Now would be a great time to create an edge server and check it out!
Hey folks! This feature was added to cPanel & WHM in Version 72, which is available in the CURRENT tier now! Take a look at the release notes, and see all of the highlights for this version on the 72 Release Site.
https://documentation.cpanel.net/display/72Docs/72+Release+Notes#id-72ReleaseNotes-NewGit%E2%84%A2VersionControlfeature
Hey folks! This feature was added to cPanel & WHM in Version 72, which is available in the CURRENT tier now! Take a look at the release notes, and see all of the highlights for this version on the 72 Release Site.
https://documentation.cpanel.net/display/72Docs/72+Release+Notes#id-72ReleaseNotes-NewGit%E2%84%A2VersionControlfeature
Replies have been locked on this page!