Skip to content
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

Have create-package use targets when generating included-files list #324

Open
dmikusa opened this issue Apr 4, 2024 · 2 comments
Open
Labels
type:enhancement A general enhancement v2 Work for v2 release

Comments

@dmikusa
Copy link
Contributor

dmikusa commented Apr 4, 2024

Describe the Enhancement

In this PR we added functionality such that create-package can generate a list of targets and add common included files, like README or LICENSE, to every architecture without needing them to be explicitly listed in the included files list.

It finds the targets by looking at the existing list of included files and looking for ones that start with linux/. If there are no targets then it falls back to the older format without linux/<arch>.

Possible Solution

We could not do this in 1.x because it requires buildpack API 0.10 support and libcnb 1.x will not get that. With v2.x libcnb will support buildpack API 0.10 and so it will have target information available. Instead of picking the targets based on the included files list, we can use the targets set in the buildpack.toml. This will make it more accurate and make it such that we can remove all the arch-specific info from included files.

If the targets list is not set in buildpack.toml, then we should fallback to the old behavior of not putting linux/<arch> on the front of things.

Motivation

Put fewer things in included files list. It's easier to maintain that way.

@dmikusa dmikusa added type:enhancement A general enhancement v2 Work for v2 release labels Apr 4, 2024
@loewenstein
Copy link

@dmikusa Should this be moved to whatever repo gets created as part of #259?

@dmikusa
Copy link
Contributor Author

dmikusa commented May 13, 2024

Probably. I think we have to decide as a team that we're going forward with externalizing the tools. I'd like to do #259, but I haven't heard from the other maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement A general enhancement v2 Work for v2 release
Projects
None yet
Development

No branches or pull requests

2 participants