extend support for variant builds #578
Conversation
| @@ -1,5 +1,5 @@ | |||
| /*! | |||
| This tool carries out a package or image build using Docker. | |||
| This tool carries out a package or variant build using Docker. | |||
There was a problem hiding this comment.
nit: I have to admit I'm hesitant about a s/image/variant/g in prose. It's not clear whether "variant" refers to a variant of a package, or what; it's clearer as an adjective. (I guess not just prose; for example, VariantBuilder is confusing to me.) I would lean toward using "image" when there's no confusion, "image variant" when there's potential confusion of image types, "OS image variant" when there's potential confusion with containers, and "variant" alone only when it's clear we're already talking about image types.
There was a problem hiding this comment.
I don't feel like this is a perfect approach by any means. I tend to err on the side of terseness if I'm not confident that verbosity would be better.
I expect "image" is always going to be ambiguous; even when it's clear we're talking about the OS, we create three images as well as a combined one, and arguably it's the set of three that's most essential.
"OS variant" seems best to me as it avoids the "image" term. But it's a bit pretentious to talk about building an OS when we're building a Linux distribution, and neither "distribution variant" or "distro variant" resonated with me.
Hence I ended up with "variant" as a singular noun to describe the composite output of each invocation of the build system.
I admit I didn't have "package variants" in mind as a concept, but I would just call that "multiple major versions of a package" and not assign it a specific term.
This shouldn't be changed until we're ready for a change in manifest format. |
Signed-off-by: Ben Cressey <[email protected]>
Previously we referred to custom OS builds as "images" or "flavors". Images as a term isn't accurate - we produce multiple filesystem and disk images for each build. Flavors is better, but is arguably a project-specific term for a more general concept. This introduces the term "variant" for our custom builds, which aligns with the corresponding field in the os-release file, and fixes up the build logic to match. Signed-off-by: Ben Cressey <[email protected]>
Signed-off-by: Ben Cressey <[email protected]>
This lets us omit the getty units in variants that do not include a shell and do not support console login. Signed-off-by: Ben Cressey <[email protected]>
Signed-off-by: Ben Cressey <[email protected]>
Signed-off-by: Ben Cressey <[email protected]>
Pull #578 added support for build variants to support different features and use cases, starting with aws-k8s and aws-dev. These variants use different software, and therefore need different configuration. This change allows for having a different API model (and default values) per variant. The model was moved to workspaces/models. This crate actually contains the model for each variant in separate subdirectories. Cargo's `build.rs` is used to symlink in the proper source code before build. The "proper" source code is chosen using the VARIANT environment variable. The build system passes this through using the value of BUILDSYS_VARIANT, which is set in the top-level Makefile.toml and can be overridden on the command-line. For local cargo builds, the developer must set the VARIANT environment variable; we don't currently want to choose a default model. To start out, the aws-k8s and aws-dev models (and related default values) are copies, with aws-dev having the Kubernetes-related values removed. The next step is to figure out an appropriate method for sharing structure; until then, we'll need to duplicate most changes.
Pull bottlerocket-os#578 added support for build variants to support different features and use cases, starting with aws-k8s and aws-dev. These variants use different software, and therefore need different configuration. This change allows for having a different API model (and default values) per variant. The model was moved to workspaces/models. This crate actually contains the model for each variant in separate subdirectories. Cargo's `build.rs` is used to symlink in the proper source code before build. The "proper" source code is chosen using the VARIANT environment variable. The build system passes this through using the value of BUILDSYS_VARIANT, which is set in the top-level Makefile.toml and can be overridden on the command-line. For local cargo builds, the developer must set the VARIANT environment variable; we don't currently want to choose a default model. To start out, the aws-k8s and aws-dev models (and related default values) are copies, with aws-dev having the Kubernetes-related values removed. The next step is to figure out an appropriate method for sharing structure; until then, we'll need to duplicate most changes.
Issue #, if available:
N/A
Description of changes:
This standardizes on the "variant" term (vs "image" or "flavor") and adds a developer variant that includes debugging tools (and a shell).
Testing done:
cargo make.cargo make world -e BUILDSYS_VARIANT=aws-devBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.