I am a noob in these server related work. I am writing some PHP code in my local system and has been updating my repo in github regularly. Each time I want to test my application, I copy all the files from my local system onto my server through FTP and then do it. Now I want to know whether is there a way to automatically make the commits that I make to reflect in the files in the server. Is there a way to automatically make the server get the files from the repo periodically? (say, once everyday).
Can this be done other way, like when I make a push from my local machine, the repo gets updated and in turn the files on the server also get updated?
My Server Details: Apache 2.2.15, Architecture i686 with Linux Kernel 2.6.18-194.32.1.el5
In addition to cronjobs, you can use a post-receive hook: http://help.github.com/post-receive-hooks/
If you have cronjobs you can use them. First set up the repository on your server. Then you can set up the cronjob, choose a time in which it should be executed, and then in the cronjob execute the following command:
cd your/repository/folder; git pull master origin
Perhaps explore the git archive command, which you can use to get a zip file or similar of your code. You could then perhaps use a script to copy that to your (other) server?
git archive --format=zip --output=./src.zip HEAD
will create a zip file called src.zip from the HEAD of your repo
More info:
http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
Do a "git export" (like "svn export")?
Related
I'm trying to find a good cross-platform way to deploy an npm project to a remote server over ssh (or another method). I'm specifically looking for something that copies over the files, while respecting the .gitignore (not copying files that are in .gitignore, and preserving files in .gitignore on the remote server, while pruning spare files.
Notably as a consequence of this requirement, this should neither copy node_modules nor clobber remote node_modules.
The idea is to get the source code to the server this way, and then execute commands over ssh to build it on the server, copy the dist into the appropriate location on the server, and run any other deploy steps.
I already have something that works fairly well. I set up a git repo on my server that I have a remote to locally, and I push my local changes to that remote. A post-recieve hook then takes effect and copies the source to where I need it, similar to what this describes.
This works pretty nicely, but it kind of falls apart when I want to deploy without fully committing everything, and it also feels somewhat fragile. I use a fairly complex local script to checkout a new branch, commit all working changes, and push it, but it fails on certain cases like having untracked files.
Pardon the lengthy context. tl;dr; I'm looking for other options to do this sort of deploy. It seems like rsync would be a natural candidate and I've looked into the npm rsync package, but its Windows support doesn't seem great, requiring cygwin. I've also considered copying manually with scp and leveraging a library to parse the .gitignore, but I'd like to preserve node_modules on the server (so it doesn't have to redownload everything), so I can't just overwrite the directory.
Any ideas?
It's been 14 years since I last worked with svn and appearently I have forgotten everything...
I have an existing web-project, consisting of a bunch of php, html, js and other files in a directory tree on a V-Server. Now I want to take these folders under version control and create a copy on my local machine using svn. So I installed subversion according to these instructions: https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/
Using the already-present apache2.
But now I kinda hit a roadblock. If I try svnadmin create on the existing folder, it tells me that is is not empty and does nothing really. All the questions and answers I find here and elsewhere are either
a) focussing on an already existing folder on the local machine
b) assuming more prior knowledge than I have right now aka I don't understand them.
Is there a step-by-step guide for dummies anywhere on how to do this? Or can anyone tell me in laymans terms how to do this?
I can't believe this case never comes up or that it is really very complicated.
At the risk of failing to understand your exact needs, I think you can proceed as follows. I'll use this terms:
Code: it's the unversioned directory at V-Server where you currently have the bunch of php, html, js and other files
Repository: it's the first "special" directory you need to create in order to store your Subversion history and potentially share it with others. There must be one and there can only be one.
Working copy: it's the second "special" directory you need to create in order to work with your php, html, js... files once they are versioned and it'll be linked to a given path and revision of your repository. At a given time there can be zero, one or many of them.
Your code can become a working copy or not, that's up to you, but it can never become a repository:
$ svnadmin create /path/to/code
svnadmin: E200011: Repository creation failed
svnadmin: E200011: Could not create top-level directory
svnadmin: E200011: '/path/to/code' exists and is non-empty
Your repository requires an empty folder but it can be located anywhere you like, as long as you have access to it from the machine you're going to use in your daily work. Access means it's located in your PC (thus you use the file: protocol) or it's reachable through a server you've installed and configured (svn:, http: or https:).
$ svnadmin create /path/to/repo
$ 😎
Your working copies can be created wherever you need to work with your IDE. It can be an empty directory (the usual scenario) or a non-empty one. The checkout command retrieves your files from the repo and puts them in the working copy so, at a later stage, you're able to run a commit command to submit your new and changed files to the repository. As you can figure out it isn't a good idea to create a working copy in random directories because incoming files will mix with existing files. There's however a special situation when it can make sense: when the repository location is new and is still empty. In that case you can choose between two approaches:
If you want code to become a working copy, you can check out right into in and then make an initial commit to upload all files:
$ svn checkout file://path/to/repo /path/to/code
Checked out revision 0.
$ svn add /path/to/code --force
A code/index.php
$ svn commit /path/to/code -m "Import existing codebase"
$ Adding /path/to/code/index.php
$ Transmitting file data .done
$ Committing transaction...
$ Committed revision 1.
If you don't care about code once it's stored in the repository or you want your working copy elsewhere, you can import your files from code and create a working copy in a fresh directory:
$ svn import /path/to/code file://path/to/repo -m "Import existing codebase"
Adding code/index.php
Committing transaction...
Committed revision 1.
$ svn checkout file://path/to/repo fresh
A fresh/index.php
Checked out revision 1.
I am using SVN update to update my web directory on my linux server. when I do an sudo svn update it says theres a conflict. i choose the accept theirs full option which Im assuming it should pull the full repo file but it never seems to replace the file. SVN reports update status G but the file remains the same.
what is going on, how do i get the depot version. This is on a server so there should never be a modified file or conflict to begin with.
Revert all local modifications (and conflicts) after update:
svn revert -R <path>
Be careful, it wipe all your local changes
It turns out what I was doing was correct, but their was an old cron job I wasn't aware of that was updating the file on the server outside of SVN. So everytime I committed a change it was overwritten by a cron job kicking off an rsynch.
So I had been (stupidly) making changes directly on the live server instead of making them on my local machine and deploying them. This messed up my deployment. So now I was to do "git reset --hard".
On my remote server I have a project.git directory (for the repository... which is bare btw) and a project directory (for my actual application).
But when I try to run "git reset --hard" it tells me I'm not on a working tree. If I go into config and change bare to false... it says the same thing.
Ideas?
Found a better solution. :)
First I did a git reset --hard on the local server (since the remote server is just a bare repository.)
Then I did a git commit -a which told me there were no changes but that there were untracked files.
So I did a git add . to add all the files that weren't being tracked.
Finally I ran git commit -a again and git push.
This updated my repository with all the new files and then cap deploy functioned as expected.
We've got a "bare" git repository on a server, for a Web portal project. Several programmers, designers, etc... perform dozens of push and pull from/to it.
Now we want to test the project on the server itself, and always test the last commit through an Apache web server which is installed on the same machine the "bare" git repository is stored in.
How can we 'unbare' the repository, and let the working directory contain always and only the last commit deriving from the last push?
Or anything else aiming to achieve the same result?
You can use a post-receive hook to do a git pull inside your webserver document root/repository.
in your bare repository
do
mv hooks/post-receive.sample hooks/post-receive
chmod +x .git/hooks/post-receive
the post receive should be something like
#!/bin/sh
WEB_ROOT='/var/www/project'
cd $WEB_ROOT
git pull
A more elegant solution that doesn't involve that the web server area being a git repository, you can also review the git documentation about hooks
Note: if you use the simple solution, please make sure that your webserver doesn't serve the .git directory, this would give some hackers/crackers the access to the website source code!