-
Notifications
You must be signed in to change notification settings - Fork 288
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 asset package creation #1085
Conversation
This is more of a meta-point, but what do you think about calling the command As we're close to finished with #597, I'm hesitant to add more commands which don't fit in with the new paradigm we're trying to follow. |
9966d9f
to
6d67a28
Compare
1bb5ff1
to
fcd8a86
Compare
Codecov Report
@@ Coverage Diff @@
## main #1085 +/- ##
==========================================
- Coverage 80.97% 80.55% -0.42%
==========================================
Files 136 155 +19
Lines 8305 9219 +914
==========================================
+ Hits 6724 7425 +701
- Misses 1156 1341 +185
- Partials 425 453 +28
Flags with carried forward coverage won't be shown. Click here to find out more. |
335ad43
to
9f93ecd
Compare
179da37
to
f109c75
Compare
3b7ebba
to
55d88f3
Compare
@dwillist I wonder if this feature should only be supported for buildpack API |
f42f95b
to
931f688
Compare
Given that this feature is tied to a spec change, we need to take special precautions. Options:
EDIT: provided more context/clarity |
PR overviewAs things stand I think this is ready for PR review, I'll be updating this comment with additional acceptance testing materials for folks if the want to use them. Whats implementedNote that all of the below are hidden behind
Whats left to do.Once there is a lifecycle release that solidifies the
|
@dfreilich any chance you could take a look at this? I know its pretty large but would be nice to try and get this into the next release if possible. |
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.
This is only a partial review - I still have to check over the 2nd half of the files.
Largely, this is super super impressive work. I haven't validated that it works, but architecturally and cleanliness, this is really 🤩 .
One thing I'm not a fan of at the moment is the command name - maybe it's overkill, but I'd really rather it be pack asset create
, rather than create-asset...
, to fit with our general pattern (and it opens the door for us to make our architecture a bit more pluggable, once all of the commands follow the same general pattern). Great work though!
os.RemoveAll(tmpDir) | ||
imageManager.CleanupImages(repoName) | ||
}) | ||
it("adds assets to build and allows buildpacks to access them", func() { |
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.
Same complaint as the first test - this is very heavy, and it also follows a similar path in preparation as the first test. Try to refactor this, preferrably into a dedicated AssetPackagesManager
or XBuildpack
.
@@ -2621,6 +3019,137 @@ func createComplexBuilder(t *testing.T, | |||
return bldr, nil | |||
} | |||
|
|||
func createBuilderWithAssets( |
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.
When possible, I'd rather we err towards taking things out of this file, rather than into this acceptance test. I'm not sure if this is the place to do it, but we really should have a BuilderManager
(as I mentioned here #673 (comment)) to take care of builder prep.
acceptance/acceptance_test.go
Outdated
func cleanAbsPath(path string) string { | ||
return strings.ReplaceAll(path, `\`, `\\`) | ||
} |
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.
Can we put this in a more central place? testutils
, perhaps?
acceptance/acceptance_test.go
Outdated
return strings.ReplaceAll(path, `\`, `\\`) | ||
} | ||
|
||
func imageSha(t *testing.T, assert h.AssertionManager, dockerCli client.CommonAPIClient, repoName string) string { |
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.
This should go into the imageManager
or ContainerManager
. It may already exist, honestly
|
||
// CreateAssetPackage writes a new Asset Package image using options specified in opts. | ||
// This image can be used to add assets to builds. | ||
func (c *Client) CreateAssetPackage(ctx context.Context, opts CreateAssetPackageOptions) error { |
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.
Overall, this func reads really well. It's decomposed super nicely. Great job!
create_asset_package.go
Outdated
return result | ||
} | ||
|
||
// this method mutates the given assetImg |
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.
This comment doesn't really add much
create_asset_package_test.go
Outdated
func assertLayerHasFileWithContents(t *testing.T, rc io.ReadCloser, path, expectedContents string) { | ||
t.Helper() | ||
|
||
_, actualContents, err := archive.ReadTarEntry(rc, path) | ||
h.AssertNil(t, err) | ||
h.AssertEq(t, string(actualContents), expectedContents) | ||
} |
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.
Can we add this to testutils
, in case it's useful in other tests?
internal/asset/fetcher.go
Outdated
// ImageFetcher is implemented by Fetcher which allows work with remote and local images, | ||
// as well as control when images are used locally vs pulled remotely. | ||
type ImageFetcher interface { | ||
|
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.
nit
} | ||
|
||
// GetLocatorType parses a locator and returns the LocatorType | ||
func GetLocatorType(locator string, relativeBaseDir string) LocatorType { |
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.
Is there some way we can combine this with the existing locator
searching mechanism, or is it totally unfit/unintuitive to do so?
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.
Definitly could but it would likely take quite a bit of work here to pull out all the buildpack
locator specific logic. Was thinking this would be part of the larger refactoring story.
@dwillist I was waiting until the conflicts were resolved, because changes will have to be made, but I made an initial pass. I'll make another pass at some point soonm, to give some more detailed feedback on the 2nd half of the PR. |
Signed-off-by: dwillist <[email protected]>
Signed-off-by: dwillist <[email protected]>
Signed-off-by: dwillist <[email protected]>
Signed-off-by: dwillist <[email protected]>
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.
I've checked it over (not quite as in depth as I would like) and it definitely seems to be good.
To be honest, I don't have the time allocated to the project right now to give it the in depth review it really needs (on the scale of 4+ hours, I would assume), and its current iteration as one massive PR isn't the most conducive for it being a comprehensively reviewed PR, unfortunately. At the same time, since it's gated with an experimental
flag, I'm ok merging it in, assuming that there will be further refactors and simplifications/combinations (for instance, seeing whether we can combine some of the primitives which seem to be redefined, such as the separate Fetchers, locators, etc).
Given that (and how long it's been waiting), I'll give it a approval now, but would definitely appreciate smaller PRs in the future 😅
@dwillist Looks like there's some issues with acceptance tests which needs to be fixed before merging |
Based on efforts to unify caching (see buildpacks/rfcs#171) the original RFC has been put on Hold. Closing this PR (at least for now). |
Signed-off-by: dwillist [email protected]
Summary
Implement
asset-cache
creation as specified by #1055This adds the experimental
create-asset-cache
command that works as follows:pack create-asset-cache <image-name> --buildpack <buildpack locator> --publish(optional) --pull-policy(optional)
Additionally it adds support for using asset caches when
pack build
with the--asset-cache
flag(side UI bug, localbuildpack
require afile://
prefix...Documentation
Related
Implements first part of #1055