Add (write), (publish), and (docker-build)
#270
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bit of a hefty PR, since I was using these changes to refactor the Buildkit image building process, which is included in this PR.
The broad theme of these changes is to whittle away at scenarios where you have to fall back on Bash or other external tools, and to embrace compatibility with the goal of letting you use Bass for the end-to-end lifecycle of image building and publishing.
Add
(write)for writing to diskThe first thing I noticed was I had an explosion of scripts involved in bumping Buildkit and building its image. I had Bass scripts that did "pure" things like emit a thunk or thunk path to stdout, and then Bash scripts that piped the exported to the filesystem.
The thought behind this was to keep Bass "sandboxed" so it's not able to write to the host filesystem. But dealing with these wrapper scripts is just way too painful.
Now it's possible to write to the host, with two safeguards:
HostDir. You can't write to arbitrary paths.bass.Filesystemabstraction. By default it uses the host filesystem, but something integrating with Bass (e.g. Bass Loop) can override it with a read-only or empty filesystem.HostPathin the first place, but it's still nice to support sandboxing.In addition, writes are atomic. This makes it easy to pass a file to a command for processing and then
(write)the result to the same file. Without atomic writes it would truncate the input before/while it's being processed, which is a common footgun in Bash.Add
(publish)for pushing a thunk to a container registryAnother thing I relied on Bash wrappers for was pushing images to a container registry. Now you can just
(publish)directly from Bass. No need to(export)to disk and then pass toskopeoordockerfor pushing. Much faster!Add
(docker-build)for building from DockerfilesYou can now build images using good old
Dockerfiles. I needed this because I wanted to be able to use a fork of Buildkit by building from theDockerfilein its repo.Currently this is its own special type of image, slotting in alongside OCI archive images, image refs, and thunks. So you don't 'build' a Dockerfile into a Thunk, you can just use it as an image.
This will allow for far greater compatibility with the external world. Bass doesn't replace Dockerfiles; it's far too opinionated. Dockerfiles will probably exist until the end of time if not just as a language-neutral format for building images.