Tag images based on tool version

[ekilmer]

Thinking about best practices for reproducibility, it would be necessary to have tagged Docker images for each tool based on version releases.

Although it is unlikely for formatting to change on releases of mature tools like clang-format, it isn't guaranteed, so if a project or developer wants to use a specific version of a formatting tool for a while then there is no way to do that as of now.

Of course, there are almost an infinite number of ways to organize the tagging system, so I'd like to hear what anyone thinks would be helpful.

I am thinking of at least 3-tier system for image tagging:

1. :HEAD - Latest version of source code for tool pulled from git master or wherever latest development takes place (it could also be a separate branch if the author likes to keep master branch stable and do next-release dev work on a dev branch). This could run nightly in travis (maybe rename tag to :nightly?).
2. :latest - Latest stable version release of the tool. This should follow the latest tagged/versioned release of the tool.
3. :$major.$minor - A tagged major and minor version of the tool for people who like to update dependency versions manually.

Since there are so many tools with guaranteed different methods of versioning, it would be smart to implement this in a way that leaves room for someone to maintain tags at a more granular level like :$major.$minor.$patch or something.

Thoughts? Comments? Concerns?

As for implementation, I haven't thought too hard about how to use Travis most effectively (i.e. build only :HEAD unless there is a new version release). To detect new releases, maybe there is a way to automatically tag by looking at a tool's git/svn tags? This would be a natural correspondence for docker image tags and releases.

[stevenzeck]

Hi @ekilmer, I like this idea. I don't think we would ever build images from dev branches, but tagging via latest and major.minor.patch would be helpful in the long term.

One thing though, and it will take review of most if not all of the Docker images, is that we're not always controlling the version of the tool being installed in the Docker image. For php-cs-fixer we are, but phpcbf we are not. So we'll have to add some control mechanism for those.

[MartinDelille]

I'll be interested by this feature!

I'm using uncrustify to lint my code and every new release may change the output. Finer control of the uncrustify version would allow me to accord my local version with the continuous integration service.

Could you tell me how do you see the implementation? I would drop a PR if I have time to do so.

[MartinDelille]

Current uncrustify version is quite late by the way: https://github.com/uncrustify/uncrustify/releases

[ekilmer]

A small general solution might be a bit difficult to apply to all tools, just because some of the tools are already packaged with another package manager, e.g. black:

docker-beautifiers/black/Dockerfile

Line 7 in 0a35180

RUN pip install --upgrade black

and others seem to be built from source, which could have dependency changes (albeit they might be rare occurrences), e.g. clang-format:

docker-beautifiers/clang-format/Dockerfile

Lines 10 to 20 in 0a35180

	# Download and setup
	WORKDIR /build
	RUN git clone --branch ${LLVM_TAG} --depth 1 https://github.com/llvm/llvm-project.git
	WORKDIR /build/llvm-project
	RUN mv clang llvm/tools
	RUN mv libcxx llvm/projects
	# Build
	WORKDIR llvm/build
	RUN cmake -GNinja -DLLVM_BUILD_STATIC=ON -DLLVM_ENABLE_LIBCXX=ON ..
	RUN ninja clang-format

But, I believe most tools are version-controlled in a Git repo, so something like a Docker argument with the latest "stable" tag (for various definitions of "stable") or default of master branch might work pretty well, and then the Docker images could be tagged with the some variation of the Git tag/branch in CI when they've been built completely.

Then, there's the problem of keeping up to date with the latest releases upstream. You'd either need to rely on contributors to bump the versions every now and then. Or, you could develop a fancier way to query Github for new releases (like some dependency bots do).

Good luck!

[ekilmer]

Also, if you want to be efficient in the CI, you could:

• Have nightly builds of master branch for all tools.
• Only build new images for the Dockerfiles that have changed in a commit, i.e. you don't want to rebuild all tools if you only bump the version of uncrustify. I think this is similar to how some projects run linting tools on only the changed files.

[MartinDelille]

I think I'll start by handling my own uncrustify image at the begining to understand how to deal with it (I'm not a docker power user yet).

[thejohnfreeman]

clang-format changed formatting across patch versions, so it's not as stable as you might think. I won't be able to take advantage of these images until they tag specific versions and keep old versions around for some time.