All operations are automated as much as possible.
- Generation of each
Dockerfile
and its context is automated viaMakefile
.
To update versions of images following steps are required:
- Update all required versions in
Makefile
. See also: Image versioning convensions - Update all required versions in
README.md
. See also: Image versioning convensions - Edit templates
- If you need to modify some
Dockerfile
s then do it via editingtemplates/Dockerfile.erb
template. - If you need to modify some
Gemfile
s then do it via editingtemplates/Gemfile.erb
template. - If you need to modify some
conf
s then do it via editingtemplates/conf
templates
- If you need to modify some
- Regenerate all
Dockerfile
s and their context (it's okay to remove previous ones completely):make src-all
- Push changes to
master
branch.
- We use the following image versioning convension:
v<Fluentd version>-debian-<destination name>-<image major version>.<image minor version>
- Reset image version to
1.0
when bump up Fluentd version - Bump up image major version when including breaking changes on a destination
- Bump up image minor version when updating gems on a destination
Note: This procedure requests that the specified Fluentd debian tag image is already published in Fluentd DockeHub's tags page.
Note: This procedure requires fluent/fluentd-kubernetes-daemonset
repository's DockerHub Admin
privileges.
Go to Build settings page and then, push [Trigger ▷]
buttons.
When Fluentd is bump up every minor version (e.g. v1.12 to v1.13), we need to reconfigure Dockerfile location
via [Configure Automated Builds]
button.
Built tags will be published at TAGS page.
Tests are outstanding
It's still possible to build, tag and push images manually. Just use:
make release-all
It will build all existing Dockerfile
s, tag them with proper tags
(as README.md
requires) and push them to Docker Hub.