Add ostree commit resolver for otk: otk-resolve-ostree-commit (COMPOSER-2349)

[achilleas-k]

New cmd for resolving ostree commits for otk.

The resolver is a simple call to ostree.Resolve() which handles resolving ostree input options to an ostree.CommitSpec.

The resolver returns the input as-is when the ref is a commit ID (there is nothing to resolve). This can happen when a user wants to pull an ostree commit by its ID rather than specifying a ref to resolve.

[supakeen]

Just one little bit and maybe @mvo5 can chime in here but I think these outputs should live under a tree.const similar to the otk-gen-partition-table and osbuild-gen-depsolve-dnf4 externals that generate defines.

[achilleas-k]

Just one little bit and maybe @mvo5 can chime in here but I think these outputs should live under a tree.const similar to the otk-gen-partition-table and osbuild-gen-depsolve-dnf4 externals that generate defines.

Ah, yes. Probably. Though, I'm not entirely sure what our rules and conventions are exactly.

Given the way we describe the Const object

images/internal/otkdisk/partition.go

Lines 23 to 25 in fa40f2d

	// Const contains partition table data that is considered "constant",
	// i.e. that should not be modified by the consumer as there may be
	// inter-dependencies between the values

I think it's more appropriate for outputs from externals that will be fed back into another external.

The output from the resolver here is going to be used directly in stage options, so it's probably not necessary to mark them as const. Though maybe it's still a good convention to specify that modifying one or more might lead to inconsistencies.

[supakeen]

Just one little bit and maybe @mvo5 can chime in here but I think these outputs should live under a tree.const similar to the otk-gen-partition-table and osbuild-gen-depsolve-dnf4 externals that generate defines.

Ah, yes. Probably. Though, I'm not entirely sure what our rules and conventions are exactly.

Given the way we describe the Const object

images/internal/otkdisk/partition.go

Lines 23 to 25 in fa40f2d

	// Const contains partition table data that is considered "constant",
	// i.e. that should not be modified by the consumer as there may be
	// inter-dependencies between the values

I think it's more appropriate for outputs from externals that will be fed back into another external.

The output from the resolver here is going to be used directly in stage options, so it's probably not necessary to mark them as const. Though maybe it's still a good convention to specify that modifying one or more might lead to inconsistencies.

That is definitely a discussion we could have for now I think we can go with mashing it under const and then have a separate discussion about it when we have this one and the container resolving one in as well (we'll have 4 externals by then).

I mostly understood the adding of const to mean 'dont assign to this'.

[mvo5]

Thank you! I added some comments but feel free to ignore, mostly nitpicks/ideas/suggestions.

About the const vs inteneral. I'm happy to have a discussion here if needed, in my head it was mostly this heuristic:

• const means that if a consumer modifies it things may fall apart/become inconsistent but const itself is fine to be used in an otk manifest and things under it are an API that we cannot easily break
• internal means to be used only by internal tooling, i.e. matching producer/concsumer externals, anything under it is not an API and can change anytime as the consumer/produce pleases

[achilleas-k]

The Output has been Consted.

[mvo5]

Thank you!

[supakeen]

Needs the other comments resolved, awesome.