signet/git repository overview

⁠Run the container

⁠Using HTTP(S)

⁠Interactive

docker run \
--rm \
-v ${PWD}:/repos \
-it signet/git clone https://[email protected]/this/proj/repo.git /repos/repo

Cloning into '/repos/repo'...
Password for 'https://[email protected]':
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 10 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.

⁠Non-interactive

docker run \
--rm \
-v ${PWD}:/repos \
signet/git clone https://user1:[email protected]/this/proj/repo.git /repos/repo

Cloning into '/repos/repo'...
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 10 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.

⁠Overview

There are a number of capabilities that we are containerizing for the sake of automation. Containerizing utilitarian programs such as Git, give us the ability to modularize the build and deployment pipeline. In this fashion, we are able to re-use these capabilities at any given point in the pipeline simply by spinning up this container. This accomplishes two major things that are of benefit to us:

1. It standardizes the toolset. For instance, we can spin up this container over and over again, and it will always run the same version of Git with any and all its necessary dependencies.
2. The load can be distributed effectively by the CI/CD tool. Since we containerize the Git capability, the only requirement that any build server needs to fulfill, is that Docker is installed. Therefore if we have a cluster of nodes running Docker, any node available in that cluster can run the Git capability without ever needing Git installed on the node. This not only goes for Git, but for any other service or utility we have a container designed for.

⁠Volumes

In our examples, we specify a volume such as:

-v ${PWD}:/repos

Obviously this volume can represent any local file system location and any container location. You just have to make sure that whatever location the local file system is mounted to inside the container, that your Git command corresponds. For example if you are cloning a repo, then you must specify the clone location that corresponds to the mount point in the container.

...
-v ${PWD}:/repos \
... clone ...repo.git /repos/myrepo

In the example above, the local file system is mounted into the container at /repos. Therefore, we need to clone the repo to the "/repos" directory in order to persist the clone outside of the container. In this case the "repo.git" repo would reside in "/repos/myrepo" in the container, and in "${PWD}/myrepo" on the local file system.