src/cmd-build: Add ostree target

[jlebon]

I'm often just iterating on the OSTree content itself and don't require
new images. In such cases, it's a waste of time to wait for images to be
generated when all I want is the treecompose. But using
coreos-assembler build is still more convenient than dropping down to
rpm-ostree compose tree, especially with the virtualization wrapper.

Add a new --ostree-only option in which we only generate a commit to
the OSTree repo. This is a natural extension of #302. Crucially though,
we still create a build directory under builds/ with metadata about
the built commit. The only practical difference is that there are no
image files and no subkeys under images in meta.json.

(I didn't bother breaking the idempotency coupling here wrt the
kickstart since (1) it's going away, and (2) this is really just for the
local dev case where you're iterating on the tools, like rpm-ostree, or
the content, like the treefile.)

[cgwalters]

LGTM!

[dustymabe]

I almost think this would be better served as part of the [IMAGETYPES] (better name needed maybe).

So we would default to [ostree qemu], but you could specify cosa build ostree to just build the ostree.

[jlebon]

Hmm yeah, I think I like that.

[jlebon]

Done! (With the tweak that any of the image types automatically implies ostree, so the default internally is still just qemu).

[dustymabe]

LGTM

[miabbott]

Ran an unprivileged build of RHCOS for ostree and qemu targets successfully.

One nit: if you run build ostree, then build qemu you have to specify --force. It might be nice to teach build to have some intelligence to recognize an ostree exists and images can be produced from it.

That being said, this WFM, so 👍

[jlebon]

Awesome, thanks for testing! 👍

It might be nice to teach build to have some intelligence to recognize an ostree exists and images can be produced from it.

Hmm, maybe. Though that would blur the line between build (creates new builds) and buildextend-* (appends to an existing build). Or what we could do is tweak things and just imply --force if the targets are not the same as the last build?

[miabbott]

Or what we could do is tweak things and just imply --force if the targets are not the same as the last build?

That seems like a good compromise; but let's not hold up merging this on that idea.