~kdsch/howto-git-http-ci-container

How to run Git with HTTP auth in CI in a container
README.md: use a more precise heading

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~kdsch/howto-git-http-ci-container
read/write
git@git.sr.ht:~kdsch/howto-git-http-ci-container

You can also use your local clone with git send-email.

#How to run Git with HTTP auth in CI in a container

We'll build up a solution one piece at a time.

#Authing with HTTP

Git servers vary in their support of protocols.

SourceHut does not support password auth over HTTP. SourceHut supports write access only using SSH, and does not support read access for private repositories using HTTP.

Some Git servers support only HTTP auth, and refuse to use SSH. I do not like them.

GitLab supports HTTP auth. To reduce the number of interactive credential prompts, you can use a credential helper. You'll only have to answer a prompt for the first auth attempt. After that, the credentials are stored indefinitely. Append this to your Git configuration:

# git config
[credential]
	helper = store

Put this in the global Git configuration unless you have some reason not to.

#Authing with HTTP in a continuous integration environment

When Git is used in a CI context, there is no user to answer interactive prompts. This means

  • a credential helper must be used
  • the credential file must be provided to the CI environment as an asset

The credential helper isn't designed to work non-interactively. Users are not supposed to write the credential storage file by hand. This implies that the correct way to generate the credential file is to run a Git command that requires auth. Ideally, this action would not modify the state of either the local or the remote repository.

To generate the credential file without modifying the state of either the local or the remote repository, use the --dry-run option. For example,

# shell
rm ~/.git-credentials
git push --dry-run gitlab master

prompts for username and password, generates a Git credential file, and doesn't update the remote.

This step has to be done for each remote that requires HTTP auth. For example, this might be Git servers that host private code only over HTTP.

#Running Git inside a container

There might be a need to use SSH keys and credential helpers inside a container. This can be done by mounting volumes when running the container. For example, to give the container access to SSH keys, you would do this:

# shell
docker run --volume=$HOME/.ssh:/home/user/.ssh ...

Global Git configuration might also be desired in the container. The number of mounts can be reduced by putting the Git credentials in ~/.config/git/credentials:

# git config
[credential]
	helper = store --file ~/.config/git/credentials

# shell
docker run \
	--volume=$HOME/.ssh:/home/user/.ssh \
	--volume=$HOME/.config/git:/home/user/.config/git \
	...

This will allow the container to access the host's global Git configuration, SSH keys, and Git credential files.