cmd-buildprep: Add --ostree flag to download full commit

[jlebon]

Add an --ostree flag to also download the OSTree commit. This is
needed to close a gap where only the image input changed, so no new
OSTree content is created, and so we need the full OSTree content in
order to build the new images.

[dustymabe]

where only the image input changed

What are the sources of image input change today? image.yaml? Anything else?

[dustymabe]

Are you proposing we use this in the fcos pipeline today to handle a gap in our logic where the image.yaml changes but the ostree doesn't?

I'm trying to imagine exactly where we are going to use this.

[jlebon]

What are the sources of image input change today? image.yaml? Anything else?

Yeah, and the commit itself.

Are you proposing we use this in the fcos pipeline today to handle a gap in our logic where the image.yaml changes but the ostree doesn't?

I'm adding the flag for completeness and so we can at least ask that question. I don't have a strong opinion on whether we should use it in the pipeline. It's a corner case, and in practice, we can always force a rebuild if it's a prod release and e.g. we do a final tweak to image.yaml. OTOH, CentOS CI has very good download speeds...

Thinking more on this, we could download the commit only if we need it. I'm not convinced it's worth the added complexity though.

[dustymabe]

Is there a case where we run the pipeline it creates a commit and image.yaml (call it 30.20190912.0) and then we immediately change the image.yaml and run it again. What would you expect to happen in that case?

• Would we get a new buildID?
• Doesn't the OSTree already have the version embedded in it?

[cgwalters]

and then we immediately change the image.yaml and run it again.

This is an interesting corner case that is explicitly handled by the build code today - you get a -1 appended to the cosa image, but the ostree version stays the same.

[jlebon]

Right, this brings up an interesting side of this discussion, which is that for FCOS, we'd like to not have -1 style builds to keep things simple and clean (i.e. another way to say this is that we want the build ID to always match the OSTree version). This will in fact be easy to enforce because versioning will be driven from outside.

So this argues for not using it in the pipeline, so that we don't mistakenly hit this until we implement external versioning control. (That said, there's no reason why buildprep shouldn't support this.)