How to manage my Own project on server using Git version control.
Is there any tutorial for creating Server and adding project using Git commands.
I don't completely understand what you mean by creating server.
But if you mean creating a repository, then what you can do is go to one of the following websites and create a free account based on your need:
Github: https://github.com
Bitbucket: https://bitbucket.org
Now the above two have following features:
Github support unlimited free public respositories, and paid private repositories.
Bitbucket supports unlimited free private repositories.
You can start with creating a free account. Then go to your project repository root folder and execute the following commands in the same order:
for instance using bitbucket: -
git init
git remote add origin git#bitbucket.org:username/abc.git
echo "Anil Gupta" >> contributors.txt
git add contributors.txt
git commit -m "Initial commit with contributors"
git push -u origin master
Thereon you can follow this tutorial:
https://www.tutorialspoint.com/git/git_tutorial.pdf
Cheers!
I want to install OpenShift using the advanced installation - method on Centos7 (EC2). But first I need to know some issues:
URL of tutorial: https://docs.openshift.com/enterprise/3.0/admin_guide/install/advanced_install.html#installing-ansible
First I need to configure the prerequisitions on the master and its 2 nodes (https://docs.openshift.org/latest/install_config/install/prerequisites.html).
When that's done the advanced installation will start.
1) Do I have to install ansible on the master only and running the installer at the end or do I need to install anything on the node (except docker)?
2) Which steps do I have to follow here: https://github.com/openshift/openshift-ansible or just download the repo and following the tutorial.
3) Is there something necessary what needs to be installed or configured which is not cited?
You are correct to start with the prerequisite steps outlined in the origin documentation.
In particular,
Ensure that you've completed host preparation steps. These steps include packages that must be installed on every system.
Ensure that you've configured host access. The ansible installer uses ssh key authentication by default so you must be able to login to each system (including the master) from the master with ssh key authentication.
Ensure that the output of hostname -f outputs the correct hostname of each system.
Once you've finished with the prerequisite steps, you will move on to the advanced installation section. Steps for installing ansible and creating an ansible host inventory can be found here. You only need to install ansible on the master. Once you've installed ansible and created a host inventory you can run the ansible playbook to begin the installation.
Afterwards, you can verify the installation and then complete follow up items such as configuring authentication, creating a router and creating a docker registry.
If you encounter any problems with the advanced installer, create an issue with the openshift-ansible project.
I installed Jenkins using apt-get install jenkins. Then I made some changes in /etc/default/jenkins (which is, as far as I know, the only way to change the Jenkins system user etc.). Now I found out that this file becomes reverted with every update (using apt-get update).
In addition I changed the owner of some files of the jenkins installation (e.g. /var/lib/jenkins, /var/log/jenkins and some others) because I changed the user under which jenkins should run. Also these permission changes are reverted after every update.
There are two solutions I could think about, both not really "nice" and clean:
Install and run the jenkins.war manually without any package management
Write a DPKG-Post-Install-Trigger that fixes the problems after every update
Does anyone have a cleaner solution for that?
Two answers occur to me
1) Download the source package that apt-get uses and modify the users, permissions etc to suit your local use. Rebuild the package and either install it from cli with dpkg -i or make your own repository for local use.
or
2) Use a tool like puppet to manage the package install and then apply the changes required locally afterwards. The puppet "package/file/service" pattern explained in various places including here https://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf shows how to do the puppet manifests for this
I installed Jenkins 1.531.1.1 on CentOS 5.5 by executing the below mentioned commands:
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
I changed the JENKINS_HOME variable in the /etc/sysconfig/jenkins file to something other than /var/lib/jenkins. I changed the default port on which jenkins runs from 8080 to 9999. I also generated the ssh keys needed to pull code from github.
Unfortunately, when I try to define the github repository url in a Jenkins job, it failed to authenticate. When I checked grep jenkins /etc/passwd, the jenkins user was no longer there. I did the whole process twice and the user seems to be getting removed. Any pointers would be helpful!
The deployment team had set up a script to automatically delete any new users created just for maintenance purposes. The fact that it happened across multiple CentOS servers actually triggered me to ask this question.
In production, I maintain two sites - beta and release. Each points to a different directory via a soft link (e.g.)
beta_public_html -> /home/scott/myapp/trunk/public
public_html -> /home/scott/myapp/branches/1.2.3/public
I'm a longtime svn user, moving to git. I'm used to deploying via svn update and changing the soft link on a new branch, things are pretty simple.
Now I'm moving to git. I still need to have the two soft links (it's a Rails app using Passenger), though now I want them to point to two different git branches ("beta" and "release", say). And I want to be able to update them via git push (or git pull).
Question Part 1: I'm not sure the best way to do this.
The way I had started to do it was to just deploy to two different remotes, e.g.
git push ssh://scott#x.com/home/scott/myapp-beta beta
git push ssh://scott#x.com/home/scott/myapp-release release
But this doesn't work because push doesn't update the working tree by default.
So I go into the remote directories and run git reset --hard the first time, and it pulls the working tree. But I push again and I can't get the new push to show up - it just stays at the initial one.
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
So, if the answer to Question 1 is that my method is fine, Question Part 2: what's wrong with what I'm actually doing? If there are hooks I should be using, can someone point me to them?
(An answer to Question 1 that says "run these seven manual steps" will not be a terribly useful answer, seeing as svn checkout + ln -s are two steps.)
Thanks. I want to get back to writing code.
The article Git push is worse than worsless has an interesting discussion about a similar issue.
One of its solution and conclusion involves:
a bare repository on the production server
a cloned repository with a hook to pull what has been pushed into the bare one
So in your case,
one bare repo on which you can push beta and release branches
two cloned repo 'beta' and 'release' with a hook to pull their respective branches from the bare repo.
In short: one step: git push. No more link to manage (since the directory no longer represent a branch in Git, unlike SVN)
Regarding the hook part, a post-receive hook in the bare repo could be all what you need
See Git Tip: Auto update working tree via post-receive hook
$ cd bare
$ chmod +x .git/hooks/post-receive
with a post-receive hook like
#!/bin/sh
cd ../../beta
env -i git reset --hard
cd ../../release
env -i git reset --hard
Note:
the post-receive hook starts out with the GIT_DIR environment variable set to the repo/.git folder, so no matter what path you 'cd' into it will always try to run any following git commands there.
Fixing this is simply a matter of unsetting the GIT_DIR.
'env -i' does just that: it ignores the inherited environment completely and uses only the supplied variables and values.
The solution is to push to single repository, which would employ update or post-receive hook.
There are a few separate possibilities to create two checkouts, which can be used in hook (on server). Going from most lightweight:
If you don't need for those two checked out directories (checked out versions) to actually be git repositories, you can simply use git-archive to export two snapshots (two branches)
git archive --format=tar --prefix=public_html/ master | (cd /var/www/html && tar xf -)
git archive --format=tar --prefix=beta_public_html/ devel | (cd /var/www/html && tar xf -)
where 'master' and 'devel' are names of branches that you wanted to have checked out. Note that --format=tar is not strictly speaking needed, as tar format is default for "git archive". You might also want to remove old contents ("rm -rf public_html/" before "tar xf -" in first line, joined with "&&", and similarly for the second line).
Alternate way of exporting files would be to use low-level commands "git read-tree" (which writes tree to index) and "git checkout-index" (which copies files from index to working area).
In this solution the repository you push into can (and should) be bare, i.e. without working directory itself.
Another solution would be for the repository you push into to have two working directories, which can be created using git-new-workdir script from contrib/workdir. Each of those working areas would have be a checkout of appropriate branch of this repository.
Then update or post-receive hook would unset GIT_DIR, go to those working areas (public_html and beta_public_html), and do "git reset --hard" there.
In this solution "checkouts" would have some git-related metainfo in them (in hidden .git directory).
Yet another solution would be to have two (additional) slave repositories. Pushing into main (master) repository would then (via hook) either push into those two slave repositories, where their hooks would do "git reset --hard" or equivalent, or go to those two slave repositories and do a "git pull" from master there.
Those two slave repositories would be non-bare, and can be [directly in] public_html and beta_public_html. In this solution "checkouts" would be full-fledged git repositories itself.
You can improve this setup by having those slave repositories to have "alternates" (alternate object database) to point to master repository (i.e. be cloned with "git clone --shared ..."); without this object database in slaves starts hardlinked to master. This of course is possible only if master and slaves are on the same filesystem.
Note this solution allows for master repository to be on different host than slave repositories. (although I guess this is flexibility you don't need).
Finally you can instead of current setup deploy gitweb or some other git web interface (see InterfacesFrontendsAndTools and Gitweb wiki pages for a partial list), so that your users can browse different versions and different branches of your repository at their leisure.
In gitweb (and I guess also in other git web interface) thanks to path_info URL support you can view files in browser, and follow links correctly (if they are local), see e.g. git.html from 'html' branch of git.git repository at repo.or.cz.
P.S. "git push" does not update working directory in remote repository by default, because if somebody is working in the non-bare repository you push into, such sideways push can be very unexpected and lead to loss of work.
I use a post-receive hook like this to publish my website, because Git does not touch the working directory when doing a push. The remote repository is a non-bare repository, i.e. it has a working directory.
if [ -n $GIT_DIR ]; then
# Current dir is "<reporoot>/.git/", but we need to run reset at "<reporoot>/".
# Clearing GIT_DIR is needed, or reset will fail with "fatal: Not a git repository: '.'"
unset GIT_DIR
cd ..
fi
git reset --hard
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
When creating a bare Git repository (git init --bare) which does not have a working directory, it is a convention to name the directory "something.git". When having a non-bare repository, the repository is actually in the ".git" subdirectory, so the full path is "something/.git". It seems that in either case you can leave out the ".git" part and Git will detect it automatically.
I'm not really opposed to the other solutions, but I think there's a less hack'ish "Git way" to do this. Here's what I would do:
On my server, I'd set up a sort of a centralized repository (to be managed by Gitosis or some such thing).
From the client end, I'd constantly pull from the repository, make changes and push back. Branches are ofcourse, managed automatically.
I'd pull the required branch from Gitosis into public_html/ beta_public_html of the server. I'd keep it in sync with Gitosis periodically using a Cron job. If you don't like the Cron job idea, you could always use some sort of a hook + script as the others have pointed out.