You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When packaging buildpacks using libcnb-package (and by extension, libcnb-cargo), the packaged buildpack.toml is copied directly from the source, and there is no validation that the specified target triple is actually supported by the buildpack.
Additionally, when multiple supported targets are defined in the source buildpack.toml, copying that file to the packaged output directory inherently means that it is never accurate, as libcnb-package currently only support compiling binaries for a single target triple.
We may want to consider:
Adapting the functionality of cargo libcnb package (without arguments) to package all targets in buildpack.toml, when specified. This will require mapping supported targets to appropriate (Rust) target triples.
Verifying that targets specified in buildpack.toml are compatible with the target triple we're compiling binaries for (including the default). As an example, a buildpack may include a buildpack.toml declaring support for a single target (e.g. linux/arm64), but executing cargo libcnb package will currently:
Cause binaries targeting x86_64-unknown-linux-musl (the default) to be compiled, despite the fact that the buildpack explicitly only support a linux/arm64 target.
Copy the buildpack.toml verbatim even if the compiled binary does not match the architecture.
packaged/x86_64-unknown-linux-musl/debug/foo-buildpack/buildpack.toml should never contain a linux/arm64 target.
The packaged buildpack.tomlshould probably always include a [[targets]] section specifying (at least) the os/arch (e.g. linux/amd64, for the default x86_64-unknown-linux-musl target triple, or linux/arm64 for aarch64-unknown-linux-musl), even when the buildpack.toml source doesn't specify any targets.
When packaging buildpacks using
libcnb-package
(and by extension,libcnb-cargo
), the packagedbuildpack.toml
is copied directly from the source, and there is no validation that the specified target triple is actually supported by the buildpack.Additionally, when multiple supported targets are defined in the source
buildpack.toml
, copying that file to the packaged output directory inherently means that it is never accurate, aslibcnb-package
currently only support compiling binaries for a single target triple.We may want to consider:
cargo libcnb package
(without arguments) to package all targets inbuildpack.toml
, when specified. This will require mapping supported targets to appropriate (Rust) target triples.targets
specified inbuildpack.toml
are compatible with the target triple we're compiling binaries for (including the default). As an example, a buildpack may include abuildpack.toml
declaring support for a single target (e.g.linux/arm64
), but executingcargo libcnb package
will currently:x86_64-unknown-linux-musl
(the default) to be compiled, despite the fact that the buildpack explicitly only support alinux/arm64
target.buildpack.toml
verbatim even if the compiled binary does not match the architecture.buildpack.toml
to only list targets that compiled binaries will support. In other words:packaged/x86_64-unknown-linux-musl/debug/foo-buildpack/buildpack.toml
should never contain a linux/arm64 target.buildpack.toml
should probably always include a[[targets]]
section specifying (at least) the os/arch (e.g. linux/amd64, for the defaultx86_64-unknown-linux-musl
target triple, or linux/arm64 foraarch64-unknown-linux-musl
), even when thebuildpack.toml
source doesn't specify any targets.The text was updated successfully, but these errors were encountered: