not building mantle* artifacts as part of coreos-assembler container build

[dustymabe]

The mantle* artifacts are the only ones we don't pull from somewhere else. Building them as part of the container build means that we have to download build deps, compile, remove build deps, etc..

It would be better if we could grab the mantle* software pre-built rather than have to do this.

note this mostly came up when discussing how to better leverage podman build --layers for layer caching while hacking on the coreos-assembler container sources.

[ajeddeloh]

We don't currently have official builds anywhere to my knowledge. We also don't tag mantle release very often.

[dustymabe]

We don't currently have official builds anywhere to my knowledge. We also don't tag mantle release very often.

yeah it would be something we'd have to change if we wanted this

[ajeddeloh]

The more I think about this the more I'm against it. We ought to ensure the tooling is all built the same way. Building it all as part of the container build process means its consistent. Mantle is a less critical piece since it doesn't really impact the artifacts themselves, but other tooling we write might matter more.

[dustymabe]

The more I think about this the more I'm against it. We ought to ensure the tooling is all built the same way.

Are you referring to mantle/kola here or more than that? If just mantle/kola I can't think of a more consistent way than having an official build/released binary that we import and use here. Building it as part of this container build should be pretty consistent too, but I don't see how it would be more consistent than the other way.

[ajeddeloh]

More than just mantle/kola/ore/etc. Things like go version can matter and if we have other tooling we want to build in other languages, that can matter even more.

[dustymabe]

Edited to fix my mistake (I swapped some words)

ok it might help if we separate out the conversation into two categories:

• A. source code that lives in this repo (i.e. software that is only really useful for coreos-assembler)
• B. source code that lives somewhere else (i.e. software that has other uses)

I would propose that for B we try to pull it from a pre-built location if we can. For A we agree to build it as part of the container build.

Do you agree or disagree?

[ajeddeloh]

I agree on B but disagree on A. We should absolutely build those things in the container. Why not? We gain reproducibility if we do and it makes modifying it and knowing the build environment is the same much easier.

Edit: got flipped. I meant that I agree.

[dustymabe]

I agree on B but disagree on A.

Are you saying you agree with my statement:

• I would propose that for B we try to pull it from a pre-built location if we can

but you disagree with my statement:

• For A we agree to build it as part of the container build.

?

[ajeddeloh]

Oh sorry, that was ambiguous. Also, I got mixed up. I originally actually agree with you all the way. I've edited the comment to reflect that. Sorry for the confusion.

Taking a step back, I want to draw the distinction differently:

1. Software that is packaged by fedora and for which it makes sense to use their packages
2. Software that is not packaged by fedora or for which it doesn't make sense to use the fedora packages

Everything from A would pretty much fall under 2. Some things (e.g. mantle) don't have fedora packages and it wouldn't make sense to use the fedora package if it existed since it includes things like tests which are updated much more frequently than the fedora release process. These would also fall under 2.

What I would propose is everything under 1 just be installed in the container and everything under 2 be build by the host container. IMO we should keep the number of places things are built to a minimum since as that increases so do the places things can break, introduce inconsistencies or break reproducibility.

[cgwalters]

Deduping this with #163