RFE: extending buildprep to run "plugin" scripts

[miabbott]

While exploring options for implementing a more complex RHCOS version string (openshift/os#360), I thought about extending the buildprep stage to be able to run scripts as part of the stage. These could be thought of like "plugins" to the buildprep stage.

I envisioned a buildprep directory (maybe it should be plugins?) that would live alongside the the manifest.yaml for a project. Inside the directory could be executable scripts that would perform additional actions to prep the directory for building.

For example, in RHCOS we need to do additional steps to generate repo files before we can do an actual build. Instead of requiring the build system or user to do those steps, buildprep could read the scripts in the directory and do those steps as part of the stage.

I think this idea would also change how build would operate, in that we would probably want to run buildprep implicitly when doing build.

Does this idea seem useful?

[jlebon]

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?

[miabbott]

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)

[jlebon]

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).

[miabbott]

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.

[jlebon]

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!

[dustymabe]

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?

[prestist]

We don't have any plans to add this.