Working with Github & CMSB

Hey Greg,

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!

Thanks,

Hi Daniel,

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!

Thanks again,

Greg

Hey Greg,

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.

Cheers,

Hi Daniel,

That's useful to know, thank you.

Regards,

Greg