add sdk to project schema #89
Conversation
webern
force-pushed
the
sdk-schema
branch
2 times, most recently
from
d71e833 to
9dff50a
Compare
| /// A base name for an image that can be suffixed using a naming convention. For example, | ||
| /// `registry=public.ecr.aws/bottlerocket`, `name=bottlerocket`, `version=v0.50.0` can be suffixed | ||
| /// via naming convention to produce: | ||
| /// - `registry=public.ecr.aws/bottlerocket/bottlerocket-sdk-x86_64:v0.50.0` | ||
| /// - `registry=public.ecr.aws/bottlerocket/bottlerocket-toolchain-aarch64:v0.50.0` |
There was a problem hiding this comment.
I'd like to get rid of the "magic" implicit suffixing if we can since ultimately that constrains the end user in kind of an arbitrary way.
What do you think about making the name a template like bottlerocket-sdk-{{ arch }}? That's consistent with similar patterns elsewhere in the project.
I would also recommend making the toolchain image its own explicit field, e.g. toolchain_name . But toolchain (and kmod kits) are just inherently problematic so we'll need to find a different way to deal with them at some point.
There was a problem hiding this comment.
I thought about this and didn't like the suffixing when I encountered it. I'm fine with changing to the non-magical version. It's not great to have a field in the schema that needs to be removed at some point. Any idea of a way to avoid having a schema key that is effectively temporary?
There was a problem hiding this comment.
It feels like the correct fix is to have the SDK always build a "native" toolchain, possibly in addition to the "cross" toolchain, so that the SDK itself always has the archive and we don't need to keep a second container in sync. We do something like this for Rust already, for different reasons.
I've opened bottlerocket-os/bottlerocket-sdk#137 for that.
Any idea of a way to avoid having a schema key that is effectively temporary?
Not really. We could have a fallback path, like "if the toolchain key isn't set, assume the SDK has the toolchain and use it instead".
|
Separate the specification of the |
Add the ability to specify the desired Bottlerocket SDK in Twoliter.toml.
Require the SDK to be specified in Twoliter.toml when using twoliter make.
|
Add |
Issue #, if available:
Closes #83
Description of changes:
Testing
I used this version of Twoliter without changing anything in Bottlerocket and got the expected error:
I then removed these vars from Bottlerocket's Makefile.toml and got the expected error:
I added the SDK to Bottlerocket's Twoliter.toml and the build succeeded and the correct SDK was used:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.