Roadmap

[dmeijboom]

Now that we have the basics working we should prioritize what's next. For now I'd like to focus on getting the build part polished before moving on to the dev and deploy commands.

Next up:

• Nix builder (feat: nix builder #1)
• Jib builder (for Java)
• Buildpacks builder (doesn't support writing to OCI layout)
• Podman/buildah builder
• Profiles support (Initial support for profiles #5)
• Init command

Project maturity:

• Basic checks
• Rust unit tests
• Integration tests (Config improvements and (initial) integration tests #11)
• Examples
• GitHub Action

Before v1.0.0:

• Configurable tagging
• Multi-platform images in one build
• ..?

Ideas:

• In-cluster builds
• Package existing files/folders in OCI image

[dmeijboom]

Profiles support

What I like about skaffold is that it doesn't support arbitrary values or complex flags but has a system in place which supports YAML patches based on a profile name. The benefit is that teams do not experience the well known:

Oh yeah, just pass these 1000 flags and it should work as expected!

Damn, you forgot to set <random_value_749> and now the build is broken

So, we definitely want to follow that. At the same time the patches make the configuration overly complex. After experimenting with a lot of different options I came to the following solution:

1. We will support variable substitution for all values (only strings in the initial release) similar to Bash by using the subst crate. It receives input from variables.
2. Variables can ONLY be set in profiles. Each profile has it's own map of variables.

By doing so we keep the benefits of the profile system without having to resort to YAML patches. Considering it's less customizable we might need to enhance this but let's see how far we can go from here.

[dmeijboom]

Buildah

Supporting the buildah builder should be easy as it should be similar to the docker version without having to create a dedicated exporter (since it supports the OCI image output natively). We might want to add more flags since it has more options.

[dmeijboom]

Init command

This should be fairly easy. It's just a detection algorithm that works by iterating through folders and the root. If it's unable to find a service and/or builder an error should be thrown.

Builder detection:

• Docker: Dockerfile or *.Dockerfile
• Bazel: MODULE.bazel or WORKSPACE (not sure if we should support the latter)
• Nix: flake.nix
• Ko: go.mod (then, look for the main package)

[dmeijboom]

Dev command

We can use the inotify crate to watch for file changes which trigger a build. If nothing has changed a build should take no longer than a couple of seconds (max) so this should be fine.

We will also have to parse ignore files (gitignore, bazelignore, docker ignore). By doing so we can prevent a lot of useless rebuilds.

[dmeijboom]

Performance

While we haven't worked on a proper benchmark yet the performance seems to be fine. In mixed projects (Rust, NodeJS, Docker, Bazel) it usually takes just a couple of seconds to finish if everything was cached. Ideally this would be <1s but given the stateless design I'm not sure if that's possible.

Some ideas:

• Optionally keep OCI outputs locally hoping builders can use this to speed up builds