Support docker uri for lifecycle

[rashadism]

Summary

Now can provide a docker uri for the lifecycle image in builder.toml

Output

Before

After

Documentation

• Should this change be documented?
  • [x] Yes, the possibility of using a docker uri in builder.toml should be documented
  • [ ] No

Related

Resolves #2076

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 3.10559% with 156 lines in your changes are missing coverage. Please review.

Project coverage is 79.15%. Comparing base (6fc092b) to head (43c900d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2112      +/-   ##
==========================================
- Coverage   79.72%   79.15%   -0.57%     
==========================================
  Files         176      176              
  Lines       13263    13362      +99     
==========================================
+ Hits        10573    10575       +2     
- Misses       2021     2118      +97     
  Partials      669      669              

Flag	Coverage Δ
os_linux	78.06% <3.11%> (-0.59%)	:arrow_down:
os_macos	75.81% <3.11%> (-0.53%)	:arrow_down:
os_windows	78.54% <3.11%> (-0.57%)	:arrow_down:
unit	79.15% <3.11%> (-0.57%)	:arrow_down:

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

[ep0ll]

@jjbustamante If this feature ships, isn't it possible for platform operators to create their own lifecycles? excited to see this feature shipping, and I think one should publish an article on this

[braunsonm]

@WYGIN you could already create your own lifecycle binaries pretty sure. You just had to provide them in a tar if creating your own builder.

The pack CLI during build has supported --lifecycle-image for custom lifecycles with existing builders before this as well.

This definitely makes it more accessible though 😄

[ep0ll]

The pack CLI during build has supported --lifecycle-image for custom lifecycles with existing builders before this as well.

never noticed this flag, Thanks a lot for the information

[rashadism]

@jjbustamante @WYGIN can u have a look

There is one thing I wasn't sure on how to handle. Since we are writing the lifecycle to disk, it should be removed after creating the builder. We can't defer removing that, because I think the reference is being maintained outside the function and we need it. I tried using os.MkDirTemp assuming that it would get cleaned up somewhere but it didn't work either.

[jjbustamante]

Hi @rashadism

Sorry for being late reviewing this! thank you so much for your great effort!

Local test

To test this code I did the following:

• I created a local registry running at localhost:5000
• I ran make clean build package on lifecycle latest branch to compile the latest binaries
• I ran go run ./tools/image/main.go -lifecyclePath ./out/lifecycle-*.tgz -tag localhost:5000/lifecycle:0.19.4-linux-x86-64 to create a lifecycle image and push it to my local registry (I also did it with a docker account)
• I went to samples repo and build the jammy builder adding the following line to the builder.toml

[lifecycle]
uri = "docker://localhost:5000/lifecycle:0.19.4-linux-x86-64"

I also used my personal docker account.

[lifecycle]
uri = "docker://jbustamantevmware/lifecycle:0.19.4-linux-x86-64"

In both cases, the builder was created and I managed to see the lifecycle layer in the final builder image

Takeaways

• At the end of the builder create execution, a lifecycle.tar is left in the filesystem, because of your comment that you can't remove the file because it is being used later.

My thoughts

• I am not too worried about leaving that file there, but we should document that behavior in the docs. If we want to create a temp folder one idea is to add a TempDirectory field to CreateBuilderOptions struct, the caller can clean that folder after the client.CreateBuilder method is invoked.
• Is it possible you add some unit tests scenarios?

[AidanDelaney]

Why do we want to support a docker URI for lifecycle images?

[natalieparellano]

Why do we want to support a docker URI for lifecycle images?

@AidanDelaney simply for convenience. We publish the buildpacksio/lifecycle image as well as test images for every commit in development and it would be nice to simply refer to that image instead of having to build the tarball.

Feel free to opine further if you think this should go in another direction.