rules_docker vs Source-to-Image
rules_docker
github.comSource-to-Image
github.comSide by side
| Figure | rules_docker | Source-to-Image |
|---|---|---|
| Price from | Free | Free |
| Free plan | Yes | Yes |
| Free trial | — | — |
| Open source | — | Yes |
| Windows | — | Yes |
| macOS | Yes | Yes |
| Linux | Yes | Yes |
| Self-hosted | — | Yes |
| Plans published | 1 | 1 |
| Spec score · Container Build Tools | 7.3 (#26) | 8.1 (#12) |
| License | The repository is licensed under Apache License 2.0. | The repository is released under the Apache License 2.0. |
| Purpose | rules_docker is a set of Bazel rules for pulling base images, adding build artifacts and assets, and publishing container images. | Source-to-Image is a toolkit and workflow for building reproducible container images from source code. |
Plans
In their own words
rules_docker
rules_docker has no write-up on Specifiction yet; its figures are above.
Source-to-Image
Source-to-Image is a free, Apache-2.0 toolkit for building reproducible container images from source code. It places source in a builder image, lets that container prepare the application, and outputs a ready-to-run image. A documented workflow can build from a Git repository without a Dockerfile. Builder images may provide assemble and run scripts, plus optional scripts for saving artifacts and explaining usage. Compatible builders can reuse artifacts from an earlier output when incremental settings and scripts are supplied. A .s2iignore file filters source files and directories, while .s2i/environment defines build variables that also appear in the output image. S2I can use an OnBuild strategy with images containing Dockerfile ONBUILD instructions. Examples cover Docker, OpenShift, UBI, Ruby, and WildFly. It runs on Linux, macOS, and Windows, with Docker 1.6+ and Go 1.7.1+ listed as dependencies.