lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed markdown

Browse Source
This commit is contained in:
Andy Neff 2015-07-24 22:53:46 -04:00
parent c2d25ee6b6
commit 8de97e042a
1 changed files with 25 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
docker/README.md
View File

@ -24,7 +24,7 @@ supplied to make this all easy. Simply run
All the git-lfs_* images are built automatically, and then run. The default
command is the build script. The currently checkout version of git-lfs is
copied into the docker, and ```git clean -xdf``` is run to remove any
copied into the docker, and `git clean -xdf` is run to remove any
non-tracked files, but non-committed changes are kept. Then git-lfs is built,
and a packages is created (deb or rpm)
@ -37,7 +37,7 @@ To only run certain docker images, supply them as arguments, e.g.
And only those images will be run.
There are a few environment variables you can set to easily adjust the behavior
of the ```run_docker.bsh``` script.
of the `run_docker.bsh` script.
REPO_HOSTNAME - Override the hostname for all the repos generated/tested (see below)
@ -45,9 +45,9 @@ BUILD_LOCAL - Set to 1 (default) to use the currently checked out version of
the git-lfs to build against. If it's not 1 the released archived is downloaded
and built against. Currently only works for RPMs. DEB always builds the currently
checkout version. Build local only affect the version of the code used in generating
the rpms, not the scripts running to generate the rpms (e.g. ```./rpm/build_rpms.bsh```)
the rpms, not the scripts running to generate the rpms (e.g. `./rpm/build_rpms.bsh`)
DOCKER_AUTOBUILD - Default 1. ```run_docker.bsh``` always calls ```build_docker.bsh``` to
DOCKER_AUTOBUILD - Default 1. `run_docker.bsh` always calls `build_docker.bsh` to
ensure your docker image is up-to-date. Sometimes you may not want this. If set
this to 0, it will not build docker images before running
@ -70,7 +70,7 @@ you are executing has to be part of the docker image.
### Building Dockers (Optional) ###
```run_dockers.bsh``` calls ```build_dockers.bsh```, but you can still call the
`run_dockers.bsh` calls `build_dockers.bsh`, but you can still call the
script manually to get it all out of the way once while you go make some
tea/coffee.
@ -86,7 +86,7 @@ URL in the Dockerfile for git-lfs_centos_*.
This means all the compiling, yum/apt-get/custom dependency compiling is done
once and saved. (This is done in CentOS by using the already existing
```./rpm/rpm_build.bsh``` script to bootstrap the image and saving the image.)
`./rpm/rpm_build.bsh` script to bootstrap the image and saving the image.)
The script that takes care of ALL of these details for you is
@ -97,30 +97,30 @@ developer would need to test the different OSes. And create the git-lfs rpm or
deb packages.
However, in order to distribute git-lfs or build dependencies, the packages
that were installed for you by ```build_docker.bsh``` need to be saved too.
that were installed for you by `build_docker.bsh` need to be saved too.
This is currently only a CentOS problem. In order to generate THOSE rpms,
the git-lfs-full-build_* will use NON-bootstrapped images to build every package
and git-lfs and generate rpms. This takes as long as building the image in the
first place, but you don't get the benefit of a saved state. The
```./rpm/rpm_build.bsh``` script will build all of its dependencies when you
`./rpm/rpm_build.bsh` script will build all of its dependencies when you
run the dockers, making the rpms available. These images can be built by running
./docker/docker_build.bsh ./docker/git-lfs-full-build_*
This is most important for CentOS 6 where git 1.8.2 or newer is not available,
only git 1.7.1 is available, so every user either has to build git from source,
or use the rpms generated by the ```git-lfs-full-build_centos_6``` image. This
or use the rpms generated by the `git-lfs-full-build_centos_6` image. This
will only needs to be done once.
(To manually build a docker image, run
```docker build -t $(basename ${DockerDir}) -f ${DockerDir}/Dockerfile ./docker```
`docker build -t $(basename ${DockerDir}) -f ${DockerDir}/Dockerfile ./docker`
##Deploying/Building Repositories##
When ```./docker/run_dockers.bsh``` is done building git-lfs and the rpms/deb,
When `./docker/run_dockers.bsh` is done building git-lfs and the rpms/deb,
it actually creates a repository for distribution too. Each distro gets a repo
generated in ```./repos/{DISTRO_NAME}/{VERSION #}```. Just drop the repo
generated in `./repos/{DISTRO_NAME}/{VERSION #}`. Just drop the repo
directory onto a webserver and you have a fully functioning Linux repo. (See
Testing the Repositories below for more detail)
@ -128,7 +128,7 @@ The two major packages included are:
git-lfs-....* - the git-lfs package
git-lfs-repo-release....* - A package to install the repo.
When using ```BUILD_LOCAL=1```, all UNTRACKED files are removed during RPM
When using `BUILD_LOCAL=1`, all UNTRACKED files are removed during RPM
generation (except any stray directories containing a .git folder will not be
cleared. This shouldn't be the case, unless you are temporarily storing another
git repo in the git repo. This is a safety mechanism in git, so just keep in mind
@ -150,7 +150,7 @@ For private repo testing, GPG signing can be skipped. apt-get and yum can
install .deb/.rpm directly without gpg keys and everything will work. This
section is for distribution in a repo. Most if not all this functionality is
automatically disabled when there is no signing key present
(```./docker/signing.key```).
(`./docker/signing.key`).
In order to sign packages, you need to generate and place GPG keys in the right place
@ -176,7 +176,7 @@ Keep in mind, signing.key must NEVER be accidentally committed to the repo.
To prevent MANY passphrase entries at random times, the gpg-agent is used to
cache your signing key. This is done by running gpg-agent in the host, and passing
the connection to each docker image. This will be done for you automatically by
calling the ```./docker/preload_key.bsh``` script. This can be called manually
calling the `./docker/preload_key.bsh` script. This can be called manually
before any other command just to get the pass phrase entry out of the way before
you start running everything.
@ -195,10 +195,10 @@ signing keys
CentOS 5 will NOT work with v4 signatures. The rpms will be so unrecognizable
that it can't even be installed with --nogpgcheck. It should work with RSA on v3.
However, I could not get it to. It builds v3 correctly, but for some reason
the GPG check fails for RSA. However ```yum install --nogpgcheck``` does work! CentOS 5
the GPG check fails for RSA. However `yum install --nogpgcheck` does work! CentOS 5
will NOT work with 2048 bit DSA keys... I suspect 2048 is too big for it to
fathom. CentOS 5 WILL work with 1024 bit DSA keys. Either sign it with the key
instructions above and install it with the ```yum install --nogpgcheck``` OR
instructions above and install it with the `yum install --nogpgcheck` OR
create a NEW DSA key just for CentOS 5 and sign with that.
[1] https://www.digitalocean.com/community/tutorials/how-to-use-reprepro-for-a-secure-package-repository-on-ubuntu-14-04
@ -214,10 +214,10 @@ again, run
./test_dockers.bsh
(which is basically just ```./docker/run_dockers.bsh ./docker/git-lfs-test_*```)
(which is basically just `./docker/run_dockers.bsh ./docker/git-lfs-test_*`)
Remember to set REPO_HOSTNAME if you changed it for ```./docker/build_docker.bsh```
This can also be used to run a local test (on ```localhost:{Port Number}```, for
Remember to set REPO_HOSTNAME if you changed it for `./docker/build_docker.bsh`
This can also be used to run a local test (on `localhost:{Port Number}`, for
example)
An easy way to test the repositories locally, is to run them on a simple webserver such as
@ -241,7 +241,7 @@ named
where **{OS NAME}** and **{OS VERSION #}** should not contain underscores (_).
Any files that needs to be added to the docker image can be dropped in the
```./docker``` directory, since that is the context root they are built against
`./docker` directory, since that is the context root they are built against
(not the directory containing the Dockerfile like most dockers)
The docker image should run a script that write it's repo files to the /repo
@ -286,8 +286,8 @@ ignoring many Ctrl+C's
This happens a lot when calling programs like apt-get, yum, etc... From the
host, you can still use ps, pgrep, kill, pkill, etc... commands to kill the
PIDs in a docker. You can also use ```docker ps``` to find the container
name/id and then used ```docker stop``` (signal 15) or ```docker kill```
PIDs in a docker. You can also use `docker ps` to find the container
name/id and then used `docker stop` (signal 15) or `docker kill`
(signal 9) to stop the docker
2. How do I re-enter a docker after it failed/succeeded?
@ -298,13 +298,13 @@ ignoring many Ctrl+C's
3. That answer's not good enough. How do I resume a docker?
Well, first you have to set the environment variable ```AUTO_REMOVE=0```
Well, first you have to set the environment variable `AUTO_REMOVE=0`
before running the image you want to resume. This will keep the docker
around after stopping. (Be careful! They multiply like rabbits.) Then
docker commit {container name/id} {new_name}
Then you can ```docker run``` that new image.
Then you can `docker run` that new image.
4. Everything in the ./repos directory is owned by root