RFE: extending `buildprep` to run "plugin" scripts about coreos-assembler HOT 7 CLOSED

Hmm yeah, I see how this would be helpful. I'm not too fond of how magical it feels though. (To be fair though, there's already a sort of API established between coreos-assembler and the source repo provided).

In practical terms, is this just about making the pipeline look cleaner? So instead of e.g.

sh "make generate-yum-repos"
sh "coreos-assembler build"

you'd have just the latter?

from coreos-assembler.

In practical terms, is this just about making the pipeline look cleaner?

That's one benefit...cleaner pipeline and less things to remember when switching between projects. (i.e. RHCOS has that extra step, but FCOS doesn't)

In terms of the version string, I was thinking of using a script to mutate the automatic_version_prefix of the manifest before the build. (This is an alternate approach to coreos/rpm-ostree#1712)

from coreos-assembler.

You should be able to specify the version override using --add-metadata-string=version=MYCOOLVERSION instead of hacking the manifest directly. I could imagine a build --version= switch to pass this down too? (But we'd still let coreos-assembler handle the genver stuff).

from coreos-assembler.

In the case of generating a version string that includes a date, I was looking for a solution that would be mostly hands off from the user or system that is executing coreos-assembler. While it is easy for a build system to generate a more complex version string during each build, it is less intuitive for the user to do so.

My reasoning for trying to make this as seamless as possible is to reduce the difference in output when doing a build via a system vs locally. If the version had to be passed as an argument, the system would end up with a "complex" version string like 401.7.1122018+001, but if a user forgot to use that flag, they would end up with something like 47.1.

It's a minor difference, but I'm operating under the assumption that producing builds of *COS via build systems or locally should result in something as similar as possible. That being said, I'm not willing to die on this hill, so if this isn't terribly important, we can just punt.

from coreos-assembler.

Yeah, definitely agreed we want to make the local dev path as close as possible to prod. Though it depends at what level you're hacking on. :) If you want to replicate exactly what prod is doing, then there's really no substitute to setting up the pipeline yourself. This is why in the FCOS pipeline, there's a strong emphasis on local hacking: https://github.com/coreos/fedora-coreos-pipeline/blob/2f5974fe0469a24763c0b8b1837d0de9d2db75e7/HACKING.md.

I think what we're discussing here is similar in a way to #159, i.e. what should belong in the pipeline vs what should belong in coreos-assembler. E.g. hacking on host changes shouldn't involve setting up the pipeline. Hacking on versioning schemes... that one is less obvious I guess? Though I think I do lean towards the latter (i.e. either in coreos-assembler or rpm-ostree). Let's see what others think!

from coreos-assembler.

I like this idea, but there is a certain level of magic involved. I think maybe if we clearly define each stage of the build (fetch build etc..) then we could/should have "hooks" functionality for each one that serves as the plugins. i.e. a mechanism for before and after of each stage that can be defined by the configs (such as github.com/coreos/fedora-coreos-config).

WDYT about "hooks" in the name?

from coreos-assembler.

We don't have any plans to add this.

from coreos-assembler.