Updating git repo inside container

General
1

I have a command to be run inside container that depends on upto date repository to be pulled from github.
So far I’ve found the following solutions to this problem

  1. Bake repo into image. Downside is that I have to recreate image if github repo changes
  2. pull from upstream when container is first ran up. Downside is that I have to restart container to pull any changes from upstream
  3. volume mapping. Downside is that this would need to be maintained itself on the host

I’d like the repo to exist inside the container and updated inside container on a schedule (maybe even via triggers somehow).

Are there any other methods other than the 3 outline above?

2

More specifically, clone/pull the repo before you run docker build. Don’t try to run any Git commands from within your Dockerfile, and ideally don’t include a Git binary in your image. When there is a change, delete the old container and start a new one with a new image tag.

When you see posts on the forum around setting up a CI/CD system, that’s exactly about automating this workflow. Docker (among others) runs a service that will automatically rebuild your Docker images when you commit to a GitHub repository; the various cloud-based generic build systems tend to support Docker these days too; and Jenkins seems to be a popular choice here if you’re not into the all-cloud-all-the-time environment.

The workflow I’ve used at multiple employers works like this:

  1. I do my work, and open a GitHub pull request.
  2. An automated build system runs tests against my proposed PR, possibly building a Docker image along the way.
  3. A coworker (or more) reviews and approves the PR.
  4. I merge the PR into the master branch.
  5. An automated build system builds a new Docker image, and updates a pre-production system with the new image.
  6. After some manual testing and possibly other process steps, that exact same version of the image gets pushed into the production system.

I make mistakes in this sequence all the time. Always running the master code is scary, especially if you’re running in a very lightly typed scripting language where a simple typo won’t get caught until an unusual path tries to run that code and the application crashes. So this sequence has multiple points, including after code lands on master but before it’s actually in production, where it’s possible to notice an error and roll back.