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

Add asset package creation #1085

Closed
wants to merge 36 commits into from
Closed

Add asset package creation #1085

wants to merge 36 commits into from

Conversation

dwillist
Copy link
Contributor

@dwillist dwillist commented Feb 19, 2021

Signed-off-by: dwillist [email protected]

Summary

Implement asset-cache creation as specified by #1055

This 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

  • Running pack build with the --asset-cache flag
  • Adding asset caches to builders.

(side UI bug, local buildpack require a file:// prefix...

Documentation

  • Should this change be documented?
    • Yes, (whole feature to be documented upon completion)
    • No

Related

Implements first part of #1055

@dwillist dwillist requested a review from a team as a code owner February 19, 2021 05:55
@github-actions github-actions bot added this to the 0.18.0 milestone Feb 19, 2021
@github-actions github-actions bot added the type/enhancement Issue that requests a new feature or improvement. label Feb 19, 2021
@dfreilich
Copy link
Member

This is more of a meta-point, but what do you think about calling the command pack asset-cache create, instead of create-asset-cache? Do we expect any further asset-cache commands?

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.

@dwillist dwillist marked this pull request as draft February 19, 2021 15:02
@dwillist dwillist force-pushed the asset_cache branch 2 times, most recently from 9966d9f to 6d67a28 Compare February 19, 2021 17:12
build.go Outdated Show resolved Hide resolved
@dwillist dwillist force-pushed the asset_cache branch 2 times, most recently from 1bb5ff1 to fcd8a86 Compare February 19, 2021 20:03
@codecov
Copy link

codecov bot commented Feb 19, 2021

Codecov Report

Merging #1085 (89afd7a) into main (7a08937) will decrease coverage by 0.43%.
The diff coverage is 79.30%.

❗ Current head 89afd7a differs from pull request most recent head 46bba8f. Consider uploading reports for the commit 46bba8f to get more accurate results
Impacted file tree graph

@@            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     
Flag Coverage Δ
os_linux 80.02% <79.55%> (-0.51%) ⬇️
os_macos 77.87% <79.55%> (-0.20%) ⬇️
os_windows 80.47% <79.30%> (-0.41%) ⬇️
unit 80.09% <79.55%> (-0.47%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@github-actions github-actions bot added the type/chore Issue that requests non-user facing changes. label Feb 23, 2021
@dwillist dwillist force-pushed the asset_cache branch 2 times, most recently from 179da37 to f109c75 Compare February 23, 2021 07:23
create_asset_cache.go Outdated Show resolved Hide resolved
@dwillist dwillist force-pushed the asset_cache branch 4 times, most recently from 3b7ebba to 55d88f3 Compare February 23, 2021 22:26
create_asset_cache.go Outdated Show resolved Hide resolved
@ekcasey
Copy link
Member

ekcasey commented Feb 24, 2021

@dwillist I wonder if this feature should only be supported for buildpack API 0.7+ (which doesn't exist yet). Older buildpack APIs don't support assets in buildpack.toml.

buildpacks/spec#190

@dwillist dwillist force-pushed the asset_cache branch 2 times, most recently from f42f95b to 931f688 Compare March 1, 2021 19:26
@dwillist dwillist marked this pull request as ready for review March 3, 2021 16:11
@jromero jromero added status/blocked Issue or PR that is blocked. See comments. and removed type/chore Issue that requests non-user facing changes. labels Mar 11, 2021
@jromero
Copy link
Member

jromero commented Mar 11, 2021

Given that this feature is tied to a spec change, we need to take special precautions.

Options:

  1. Gate this feature behind experimental. This would allow us to add the feature in "chunks", providing the feature to users while at the same time portraying that the implementation may change based on spec changes.
  2. Don't merge set of changes related to this feature until the spec changes have been merged.

EDIT: provided more context/clarity

@dwillist
Copy link
Contributor Author

dwillist commented Apr 26, 2021

PR overview

As 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 implemented

Note that all of the below are hidden behind experimental (even the new pack build ... flags)

  • Add a pack asset-package create command
    • this command takes list of buildpacks and creates an asset cache image as an image or tarball.
    • TODO: gate the creation of packages based on a buildpack API version. We cannot really test this until we have a lifecycle that supports the new API.
  • Add the ability to add assets to a builder by specifying them in the builder.toml configuration file. (Add an example file here)
    • TODO gate the creation of builders with assets on the platform API version. Again we need to have the lifecycle release to get the actual platform API we should be gating on.
  • Add the ability to add assets to a pack build
    • again gate this ability based on the platform API that will be used by pack & the underlying builder.

Whats left to do.

Once there is a lifecycle release that solidifies the platform API and buildpack API needed to use assets we can gate the usage of asset caches around the following support table:

pack used to build supports platform api >= 0.7 pack used to create builder supports platform api >= 0.7 lifecycle supports platform api >= 0.7 conclusion
T T T CNB_ASSETS can be set in build env! and buildpacks can use it
T T F CNB_ASSETS cannot be used as lifecycle does not support API Do not allow assets to be added to builders like this.
T F T CNB_ASSETS will not be set on the builder :( and assets were not allowed on the builder when it was created. But we should support adding assets using: "pack build ... --asset-package" at build time by adding CNB_ASSETS to the environment
T F F CNB_ASSETS cannot be used as lifecycle does not support API...
F T T Cannot use assets as pack used to build does not support platform api 0.7
F T F CNB_ASSETS cannot be used as lifecycle does not support API...
F F T Cannot use assets as pack used to build does not support platform api 0.7
F F F CNB_ASSETS cannot be used as lifecycle does not support API...

@dwillist dwillist marked this pull request as ready for review April 26, 2021 04:34
@dwillist dwillist added size/lg Large level of effort and removed status/blocked Issue or PR that is blocked. See comments. type/chore Issue that requests non-user facing changes. labels May 4, 2021
@dwillist
Copy link
Contributor Author

@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.

Copy link
Member

@dfreilich dfreilich left a 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!

acceptance/acceptance_test.go Outdated Show resolved Hide resolved
os.RemoveAll(tmpDir)
imageManager.CleanupImages(repoName)
})
it("adds assets to build and allows buildpacks to access them", func() {
Copy link
Member

@dfreilich dfreilich May 20, 2021

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(
Copy link
Member

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.

Comment on lines 3329 to 3331
func cleanAbsPath(path string) string {
return strings.ReplaceAll(path, `\`, `\\`)
}
Copy link
Member

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?

return strings.ReplaceAll(path, `\`, `\\`)
}

func imageSha(t *testing.T, assert h.AssertionManager, dockerCli client.CommonAPIClient, repoName string) string {
Copy link
Member

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 {
Copy link
Member

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!

return result
}

// this method mutates the given assetImg
Copy link
Member

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

Comment on lines 425 to 431
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)
}
Copy link
Member

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?

// 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 {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

nit

}

// GetLocatorType parses a locator and returns the LocatorType
func GetLocatorType(locator string, relativeBaseDir string) LocatorType {
Copy link
Member

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?

Copy link
Contributor Author

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.

@dfreilich
Copy link
Member

@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.

@dfreilich dfreilich changed the title initial create-asset-package implementation Add asset package creation May 21, 2021
@github-actions github-actions bot added the type/chore Issue that requests non-user facing changes. label May 28, 2021
Signed-off-by: dwillist <[email protected]>
Copy link
Member

@dfreilich dfreilich left a 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 😅

@dfreilich
Copy link
Member

@dwillist Looks like there's some issues with acceptance tests which needs to be fixed before merging

@jromero jromero modified the milestones: 0.20.0, 0.21.0 Jul 14, 2021
@jromero jromero removed this from the 0.21.0 milestone Aug 25, 2021
@jromero
Copy link
Member

jromero commented Oct 6, 2021

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).

@jromero jromero closed this Oct 6, 2021
@jromero jromero deleted the asset_cache branch April 20, 2022 17:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/lg Large level of effort type/chore Issue that requests non-user facing changes. type/enhancement Issue that requests a new feature or improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants