I am trying to setup a Gitlab instance server at work and import all of the software projects from Windows Server share folder. Gitlab is running inside VM on Hyper-V and all of the shared files are hosted on the hard-drive on Windows Server without any kind of tracking of changes made to the files. I don’t have to tell you why it’s a bad idea to have it like that.
What I would like to do is to have a read-only access to samba shares to the latest revision of the project, but host the actual source code on the Gitlab. The reason for that is not everyone wants to use git client to access the latest files for the project.
Is there a proper way to automatically do git pull whenever git server has a new update, so it clones files into a folder on Windows Server as soon as changes are made?
What are they doing with it though? Id imagine they would not be working with it because how are they gonna get their changes in? Also what about branches?
Gitlab does allow you to download any commit you want in a zip without using git. Or you might wanna use releases if that fits better.
Im all for backing up your stuff but having “the last commit” is not really a backup.
There is a proper backup in place that keeps incremental copies of all files on server. The issue is that it’s all currently just stored in folders without any tracking of changes made to those files. (unless you compare two backups directly)
Other people don’t need to work with source code directly, but they do work with PDFs and Doc files regularly that they do need to edit. Making them downloadable as zip-only is not always ideal.
They can be taught to use git client to clone the repo that has the file they need, but we can probably both agree that’s it more annoying than just opening a file over samba share.
The issue is that some technical people at the company are technical at their specific area of expertise, but it doesn’t directly relate to computers or software dev.
That’s why I want to have it available as the read-only shared folder still as it’s super convenient this way. The software devs will be using git clients for pulling and commiting. It’s just that it would be nice to have all project related files stored this way you know.
Or another option would be to set up CI/CD builds on the projects, and have those CI builds put a copy of the appropriate files on the file share. That could be as simple doing a recursive copy from the local CI directory to the appropriate file share directory (so the share is only writable for the user that the CI uses).
If working on the PDFs and Docs is the work of non dev people you could also do it the other way around.
Make a read / write’able samba share. Every now and then scedule something that will commit it to the git repo.
Might be better because you see files they changed in those commits without them having to do anything for it and they can edit the files directly in the samba share.
But then it would be difficult to know what changes were made. Binary files don’t really get the diff line-by-line changes, like text files do. Also it would look like the administrator account(or account used by script) made changes.
Yeah I know, but you can still distinguish between added / deleted or modified.
I dont know how disciplined your co workers are with descriptive git commits and much less proxied once that someone has to commit on behalf of the person that does not want to use git if you go with a read only share.