-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify carton package to work with targets #323
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We recently added targets to the `include-files` list in `buildpack.toml`. The referenced files get packaged up into the buildpack. What we added were some files prefixed with `linux/<arch>/...`. These files get put into that location within the generated buildpack directory. This is to work with a new version of pack that packages multi-arch images. It packages up whatever is under each architecture directory into the image specific to that architecture. What's happened is that we now have non-architecture dependent files like the README and LICENSE which are not being included in the images. These files also need to be prefixed with the path for each architecture. Instead of putting a lot of duplicate entries into the `include-files` list, what this PR does is to take any file not prefixed with `linux/` and duplicate it for all of the detected architectures. The PR determines the list of target architectures by looking at the `include-files` list and pulling out all of the distinct `linux/<arch>`'s that it sees. This isn't the best implementation but it's all we can do with the v1.x branch of libpak because the target metadata is not present in that version of libcnb. In libpak 2.x, we'll be able to read the target list directly from `buildpack.toml` and use that instead, which is a better option. Signed-off-by: Daniel Mikusa <dan@mikusa.com>
dmikusa
added
type:bug
A general bug
semver:patch
A change requiring a patch version bump
labels
Apr 4, 2024
To test, I ran this code on a buildpack with no targets. It produced this build, which is correct.
I ran it against a buildpack with targets and it produced this output, which is also correct. Notice how it fans out the non-arch specific files into each arch-specific folder.
|
All good, here's how I tested:
|
anthonydahanne
approved these changes
Apr 4, 2024
dmikusa
added a commit
to paketo-buildpacks/libpak-tools
that referenced
this pull request
Nov 9, 2024
Signed-off-by: Daniel Mikusa <dan@mikusa.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
We recently added targets to the
include-files
list inbuildpack.toml
. The referenced files get packaged up into the buildpack. What we added were some files prefixed withlinux/<arch>/...
. These files get put into that location within the generated buildpack directory. This is to work with a new version of pack that packages multi-arch images. It packages up whatever is under each architecture directory into the image specific to that architecture.What's happened is that we now have non-architecture dependent files like the README and LICENSE which are not being included in the images. These files also need to be prefixed with the path for each architecture. Instead of putting a lot of duplicate entries into the
include-files
list, what this PR does is to take any file not prefixed withlinux/
and duplicate it for all of the detected architectures.The PR determines the list of target architectures by looking at the
include-files
list and pulling out all of the distinctlinux/<arch>
's that it sees. This isn't the best implementation but it's all we can do with the v1.x branch of libpak because the target metadata is not present in that version of libcnb. In libpak 2.x, we'll be able to read the target list directly frombuildpack.toml
and use that instead, which is a better option.Use Cases
Multi-arch support.
Checklist