-
Notifications
You must be signed in to change notification settings - Fork 292
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
Add --flatten
, --depth
and flatten-exclude
flags to pack builder create
and pack buildpack package
command
#1691
Add --flatten
, --depth
and flatten-exclude
flags to pack builder create
and pack buildpack package
command
#1691
Conversation
--flatten-layers
to pack builder create
command--flatten-layers
flag to pack builder create
command
da60304
to
1639f9d
Compare
I still need to work in the unit test coverage, and probably I will like to refactor a little bit more, but I think in general the PR is ready for review. Another thing I need to take a look is adding the |
--flatten-layers
flag to pack builder create
command --flatten-meta-buildpacks
and flatten-all
flag to pack builder create
and pack buildpack package
command
I want to bikeshed a little bit about the |
I agree with @natalieparellano on Also, is "flatten" common terminology for this? It feels more like "merge" or "combine". but if flatten is used in other places that's fine. |
Natalie's depth comments is here "flatten" is used by $ crane flatten --help
Flatten an image's layers into a single layer
Usage:
crane flatten [flags]
Flags:
-h, --help help for flatten
-t, --tag string New tag to apply to flattened image. If not provided, push by digest to the original image repository.
Global Flags:
--allow-nondistributable-artifacts Allow pushing non-distributable (foreign) layers
--insecure Allow image references to be fetched without TLS
--platform platform Specifies the platform in the form os/arch[/variant][:osversion] (e.g. linux/amd64). (default all)
-v, --verbose Enable debug logs
|
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
f33ff35
to
bef7256
Compare
@jjbustamante do you mind if we hold this until after 0.30.0-pre2? |
No problem, I am going to draft the PR again, because I am checking Nataliee's feedback |
@jjbustamante amazing work - the code seems well tested and appears to do what it sets out to do :) I added a few suggestions to hopefully improve the readability a bit, but the only that are truly blocking are: |
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Thanks for this amazing feedback @natalieparellano ❤️ .. I just added some of them, I will take a look on the Windows support and the remaining suggestions! .. |
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
I'm reviewing this today |
Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Thanks @jkutner, I just added some TODO to add more test coverage as @natalieparellano suggested, but the important things for me to fix are the Windows support and the improvement in the As we talk in the leadership meeting, I like the strategy for merging this PR to include it in the next pre-release, and I will create a new PR with the improvements mentioned above. |
@@ -0,0 +1,9 @@ | |||
api = "0.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you using buildpack api 0.3 on purpose in these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. I think I copied and paste from another similar file
With platforms introducing the ability to create flattened buildpackages[1], the idea of 1 layer = 1 buildpack is not always true anymore - a single layer can contain multiple buildpacks. This change adds to the inspector the ability to read buildpack metadata off flattened buildpacks. This fixes "jam summarize" when creating summary/release notes for flattened buildpacks. Previously it picked up the first buildpack.toml it could find in the layer, and assumed it to represent the buildpackage. [1]: buildpacks/pack#1691
With platforms introducing the ability to create flattened buildpackages[1], the idea of 1 layer = 1 buildpack is not always true anymore - a single layer can contain multiple buildpacks. This change adds to the inspector the ability to read buildpack metadata off flattened buildpacks. This fixes "jam summarize" when creating summary/release notes for flattened buildpacks. Previously it picked up the first buildpack.toml it could find in the layer, and assumed it to represent the buildpackage. [1]: buildpacks/pack#1691
With platforms introducing the ability to create flattened buildpackages[1], the idea of 1 layer = 1 buildpack is not always true anymore - a single layer can contain multiple buildpacks. This change adds to the inspector the ability to read buildpack metadata off flattened buildpacks. This fixes "jam summarize" when creating summary/release notes for flattened buildpacks. Previously it picked up the first buildpack.toml it could find in the layer, and assumed it to represent the buildpackage. [1]: buildpacks/pack#1691
Summary
This PR adds new flags to:
pack builder create
pack buildpack package
The flags will try to flatten the layers in the final image.
for both commands the following flags were added:
These flags can be used with the following combinations:
--flatten
only OR with--depth
< 0: it will flatten ALL the buildpacks layers into 1 final layer, because the default value for--depth
is < 0--flatten
and--depth
= 1: it will flatten only the top level of composites to be flattened (i.e. composites directly referenced from either the builder or directly referenced from a composite if building a buildpack)--flatten
and--depth
= 2: it will flatten the top 2 levels of composites buildpacksAnd so on
In case the users want to EXCLUDE some buildpacks for being flatten, they can use the
--flatten-exclude
flag in combination with the previous one to exclude any buildpack they want. The buildpack MUST be specify using the formatflatten-exclude '<buildpack>@<version>'
Example
For testing the feature I used the buildpacks defined in our sample repository and a
builder.toml
with the following content:Graphically we can imagine the example as follow
Output
Here we can see all the buildpacks were flatten into one layer:
It will flatten the
hello-universe
in one layer andAnd the
hello-processes
in another layerBut if we want to EXCLUDE we can do
Metadata
Inspecting the metadata
io.buildpacks.buildpack.layers
shows the
layerDiffID
value is the same for the squashed buildpacksNote:
pack buildpack package has a similar behavior
Before
When the
pack builder create
is executed without the flag, each buildpack is added into a different layerDocumentation
Related
Resolves #1595