Builds performed on Travis (the current CI used by Crystal) have been a bit behind from releases.
It appears this process requires manual build of such images (per comment here)
This also affects builds of submitted PRs.
Perhaps will be possible to:
Dockerfile used to produce these Linux targets (32 and 64bits) into Crystal repositoryThank you
:heart: :heart: :heart:
/cc @jhass @asterite
Yes, automatic docker builds would be great!
Currently, 0.20.4 is missing on https://hub.docker.com/r/crystallang/crystal/ :disappointed:
As a temporary workaround one might use the latest tag:
$ docker pull crystallang/crystal
$ docker run --rm -it crystallang/crystal crystal -v
Crystal 0.20.4 [d1f8c42] (2017-01-06)
The tag 0.20.4 magically appeared on https://hub.docker.com/r/crystallang/crystal/tags/ :smile_cat:
Thank you! :green_heart:
See if this could be integrated with #3721
@spalladino I think docker builds are best done on docker hub itself, but release builds + packaging is definitely a goal for the CI I have in mind. Then the Dockerfile then would just download a package and install it. Providing an officially-supported alpine package and docker container would also be something I would be willing to spend time doing.
Agree with @RX14, I think the final build should be built once, but can be delivered in many methods, like: Docker image, Ubuntu package, Homebrew formula, etc.
But I don't know if this is possible because Crystal depends on the host environment (like LLVM version, in some distro may provide different versions LLVM package)
Bumping this issue:
Can we setup the automatic build of docker images using tags on Docker Hub? https://hub.docker.com/r/crystallang/crystal/tags/
0.24.1 is out but the image still doesn't exist.
It's fairly easy to configure automated builds now. You can setup the master branch to create the latest image and tags to create released versions.
Branch: master -> crystallang/crystal:latest
Tag: * -> crystallang/crystal:*
Automatic docker builds from CI have been working for quite some time now. Closing.
Most helpful comment
@spalladino I think docker builds are best done on docker hub itself, but release builds + packaging is definitely a goal for the CI I have in mind. Then the Dockerfile then would just download a package and install it. Providing an officially-supported alpine package and docker container would also be something I would be willing to spend time doing.