Support (require?) storing builds in a git repository about coreos-assembler HOT 5 CLOSED

At a high level...there have definitely been some times when I wondered about using git for ostree from the start too; some of the same ideas behind bup. It's really not worth changing now though.

from coreos-assembler.

We are producing meta.json and builds.json now via our pipeline ... though these are not being stored in our git repository.

from coreos-assembler.

The following points, coming from a discussion with @jlebon, are partially related to the discussion in this ticket.

• builds in the JSON manifest are currently sorted newest-to-latest, with new builds pushed at index 0 and displacing existing one. As a consumer, I would prefer an append-only list with stable indexes.
• pruning does not fit well with cincinnati update model. An evetually-pruned release can't be discovered and inserted in the update graph. Thus, a host on a pruned release will (eventually) end-up in a EOL state where it can't auto-update anymore.

from coreos-assembler.

there are different options for pruning

• For any prod ref I don't think we'd prune aggressively at all
• We can prune content without pruning commit info (i.e. just keep the metadata but drop the content), which should allow Cincinnati enough info to operate.

from coreos-assembler.

Dup of #159

from coreos-assembler.