This repository contains Dockerfiles to build OSS products used in our project, Neco. They are built from the official sources, and based on our Ubuntu base image.
See also: github.com/cybozu/ubuntu-base.
Built images can be pulled from ghcr.io/cybozu.
Subdirectories in this repository have TAG and BRANCH files
in addition to files to build Docker images.
Each directory that contains a Dockerfile must also have a
build-targets.yaml alongside it. This file declares the build entries
(image name, scan settings, platforms, etc.) for that Dockerfile, and
its enclosing directory is used as the build context. See the header of
generate_matrix for the full list of fields.
These will be used by GitHub Actions to tag the built images. GitHub Actions does the following each time commits are pushed to a branch.
- For each directory containing
TAGfile:- Read
TAGfile and check if the repository at ghcr.io/cybozu with the same name of the directory. - If the repository contains the same tag in
TAG, continue to the next directory. - Otherwise, build a Docker image using
Dockerfileunder the directory.
- Read
- If the branch is not
main, GitHub Actions stops here without pushing. - If the branch is
main, for each directory with a built image:- Tag the built image with tag in
TAGfile. - Push the tagged image to ghcr.io.
- If the directory contains
BRANCHfile:- Tag the built image with each tag listed in
BRANCHfile.- See Branch naming section for details.
- Push the tagged image to ghcr.io.
- Tag the built image with each tag listed in
- Tag the built image with tag in
Images whose upstream version conform to Semantic Versioning 2.0.0 should be tagged like this:
Upstream version + "." + Container image version
For example, if the upstream version is X.Y.Z, the first image for this version will
be tagged as X.Y.Z.1. Likewise, if the upstream version has pre-release part like
X.Y.Z-beta.3, the tag will be X.Y.Z-beta.3.1.
The container image version will be incremented when some changes are introduced to the image.
If the upstream version has no patch version (X.Y), fill the patch version with 0 then
add the container image version A (X.Y.0.A).
If the upstream is a Debian package, the format of upstream version is X.Y.Z-PACKAGE
where PACKAGE is the debian package version. In this case, use X.Y.Z.PACKAGE as
the package version and add the container image version A (X.Y.Z.PACKAGE.A).
The container image version must be reset to 1 when the upstream version is changed.
If the upstream version is "1.2.0-beta.3", the image tag must begin with "1.2.0-beta.3.1".
If the image is built for an upstream version X.Y.Z, the branch name should be X.Y for X > 0, or "0" for X == 0.
BRANCH file can contain one or more branch names, each separated by a newline.
Example:
1.2
latest
latest is not follow the rules described in Branch naming.
In such cases, you can skip the consistency check for specific branches by listing them in a file named NO_TAG_BRANCH_CONSISTENCY which exists in the same directory.
Example of NO_TAG_BRANCH_CONSISTENCY:
latest
In this example, the consistency check for branch 1.2 is performed as usual, while the check for latest is skipped.
The ability to specify multiple branch names is provided only for limited use cases such as the latest tag.
Do not add arbitrary or ad-hoc branch names to the BRANCH file.