Hi all.

Let's track the requirements of this feature (now scattered across various PRs and issues).

Background

1. I opened Dockerfile and Docker automated builds #591 (Dockerfile and Docker automated builds)
2. Move repo to organisation #595 (Move repo to organization) was created but took a bit to complete
3. In the meantime Dockerfile and Docker automated builds #591 was closed by Remove docker bits #634 (Remove Docker bits) because I (temporarily) moved the GHCG Docker image under the ferrarimarco Docker Hub namespace

Current Implementation

ferrarimarco/github-changelog-generator is backed by the corresponding GitHub repository.

Each commit and Git tag pushed to that repository triggers a build on Docker hub and, if successful, in a new Docker image.

I am currently handling GHCG updates with Dependabot. This service automatically creates PRs to update dependencies by looking at your Gemfile.

This is the reason why I'm using a separate Gemfile even if we could get rid of it and run commands directly in the Dockerfile.

Ideas for a more refined implementation

Instead of just installing the updated Gem when available we could provide two kinds of Docker images:

1. One tagged with latest: by convention it could point to the latest (successful) build of the master branch. This image is overridden on each commit on master (if the build is ok)
2. One tag for each GHCG release tagged using the same Git tag (i.e. when you release 1.15.0 there will be a corresponding 1.15.0 docker image). This is needed to make production deployment repeatable

Thoughts?

/cc @olleolleolle @skywinder