Working with Github & CMSB
I am pleased to say that I have set up Github Desktop and this is tracking all changes I make to my CMSB project. I have also set up git hooks with a post receive file so that I can just run git push <<project-name>> and then all my changes are uploaded to the server. Great!
The only issue is that every time I push a change to one of my front-end files, it seems the /cmsb folder is being overwritten and this then causes the software to think it's being upgraded when I next visit /cmsb.
I'm not sure what the best practice is with using Github and CMSB so I was hoping someone could advise me please.
Should I try to ignore the entire CMSB folder? Should I just ignore certain CMSB files so it doesn't always try to upgrade each time I make a push? Should I do something else?
Any advice would be greatly appreciated.
It's great to hear you've been able to get a good Git workflow going; we've also been experimenting this in our development processes and I'm a fan.
My best guess regarding the repeated upgrades is that it has something to do with your settings files. Upgrades are triggered when the system detects a difference in version numbers between /cmsb/lib/init.php and what's in your settings file. If the version of your settings file on the deployment end has an older version number saved in Git, it could be getting overwritten each time you run the deployment. My recommendation would be to check your settings files (you likely have different files for your development and deployed versions), look for the "programVersion" setting, and make sure it's the same as the version you're running. If not, you can change this and commit it to your git repo.
As for "best practice" there's no 100% correct answer, as different approaches have different trade-offs. The general idea with git repos is that you only want to track files that you yourself are modifying since at its core Git is a tool for tracking file changes. This means ignoring things like CMSB core files, official plugins, uploads, etc. The reason for this is that when you update something like CMSB, you should be able to just transfer all of the files without worrying about what has and hasn't changed. The tradeoff here is that while ignoring these things makes your repo simpler and easy to work with (as well as smaller; uploads and backups can make repos very large), it removes some of the automation from the deployment process. A middle-ground approach is to ignore files that you aren't modifying yourself and also don't get updated very often. This helps keep the repo more maintainable while still saving you the most amount of manual effort.
One thing to note, however, is that once a repo starts tracking a file it is a fairly unintuitive process to ignore it again (and potentially dangerous when working with production environments), so if you're able to solve the upgrade issue and your existing process otherwise works for you, it may be easiest to leave it as-is. And if you do want to try reworking which files the repo tracks, it's often easier to just delete the repo and start from scratch.
Hopefully that gives you some info to move forward with, let me know any questions!
Thank you very much for the reply on this.
You were right about the version numbers being different so I have now updated that on GitHub and it seems to be working fine.
One other variable I saw in my settings file is:
'programBuild' => '2056',
Can you please tell me what this means and if I should change this too to avoid any issues?
I'm hoping I can keep things as they are with my git set up as I did sense that trying to stop git tracking files might be tricky!
When we're getting CMSB ready for release we may end up "building" it multiple times for a single version, so we track individual builds with the programBuild value; it's sort of a secondary version number. Though it's not used for any functionality - just displayed in a few places. As such it's generally not critical if this is incorrect, but it can be used for troubleshooting in some rare cases, so if you're already updating the version number I'd recommend updating this as well.
I have decided to commit everything to Github as I am using private repos that only I am accessing.
The one thing I noticed is that if I make any changes to the database tables using Section Editors on the live website then this updates the .ini files in /cmsb/data/schema
These changes are then not transferred to my repo and so are overwritten when I next push from my local machine.
The answer is to run a local version of the site, make any settings changes on the local machine and then push to the repo and then git push to the server.
I don't feel like I have a completely slick workflow yet but it's fairly good and I will continue to improve over time and will try to remember to share what I learn here.