search

buildpacks / rfcs

RFCs for Cloud Native Buildpacks
Apache License 2.0
57 stars 71 forks source link

RFC: Add images table (project.toml) #187

Closed pbusko closed 1 year ago

pbusko commented 3 years ago

Readable

buildpack-bot commented 3 years ago

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

jkutner commented 2 years ago

The following questions need to be resolved in order to finalize this RFC:

  1. What should the pack behavior be when mixing --tag option and [images] table?
    • Option 1: user-provided options override configuration.
    • Option 2: configuration overrides user-provided options
    • Option 3: A union of user-provided and config
    • Option 4: build fails
  2. How will this work if there are multiple images in the table and pack is running with --publish?
    • Option 1: introduce [[image.additional]]
    • Option 2: use the first image in the list as the default
    • Option 3: build fails

I'd like to propose that "build fails" for both outstanding questions is the best way to move this forward. It would more easily allow us to add new behavior in the future (like an order of precedence) because users will not rely on it to work in any way.

/cc @pbusko @hone @jromero @sclevine

loewenstein commented 2 years ago

What should the pack behavior be when mixing --tag option and [images] table?

  • Option 1: user-provided options override configuration.
  • Option 2: configuration overrides user-provided options
  • Option 3: A union of user-provided and config
  • Option 4: build fails

What about the positional argument to pack build <my-image>? One use case for specifying the image in the pack call is tagging with the release version in CI. I don't think that we should or want to force users into modifying the project.toml in their release jobs.

  1. How will this work if there are multiple images in the table and pack is running with --publish?
    • Option 1: introduce [[image.additional]]
    • Option 2: use the first image in the list as the default
    • Option 3: build fails

Option 3 basically means with multiple images in project.toml publishing of images has to be done separately, i.e. pack build followed by potentially multiple docker push calls, right? Question: What happens if I call pack build my-image:0.1 --tags my-image:latest --publish?

loewenstein commented 2 years ago

One more general remark. On a Twitter conversation involving @jkutner, a third person and myself, the topic of producing multiple distinct images in one go (think a Java and a Node app container image). I guess such a request would not clash with this one, because we would anyway need to push basically all configuration one level down then, right?

jromero commented 2 years ago

What should the pack behavior be when mixing --tag option and [images] table?

  • Option 1: user-provided options override configuration.
  • Option 2: configuration overrides user-provided options
  • Option 3: A union of user-provided and config
  • Option 4: build fails

What about the positional argument to pack build <my-image>? One use case for specifying the image in the pack call is tagging with the release version in CI. I don't think that we should or want to force users into modifying the project.toml in their release jobs.

I completely agree with your sentiment here. I think it should work out-of-the-box via option 1.

  1. How will this work if there are multiple images in the table and pack is running with --publish?
  • Option 1: introduce [[image.additional]]
  • Option 2: use the first image in the list as the default
  • Option 3: build fails

Option 3 basically means with multiple images in project.toml publishing of images has to be done separately, i.e. pack build followed by potentially multiple docker push calls, right? Question: What happens if I call pack build my-image:0.1 --tags my-image:latest --publish?

I think the main concern is cross-registry publishing. I don't know that this concern is specific to an images table in the project descriptor. Multiple images using publish should work as long as they are on the same registry (as discussed here).

Final thoughts, these open questions seem less relevant to the spec and more a part of the implementation. I'd be happy to resolve these questions as part of the implementation.

My only outstanding concern is about the structure. I'm still not convinced about the image URI breakdown to components as discussed here.

hone commented 2 years ago

Outstanding question is how we want serialize image references. @jromero and @jkutner to hammer out details here.

jromero commented 2 years ago

@pbusko have you had any chance to talk more in depth with individuals about that outstanding concerns in this RFC? I'd love to discuss how we can move this forward.

hone commented 2 years ago

@jkutner are you still interested in this RFC?

loewenstein commented 2 years ago

I think from our end, as providers of a platform, what's still left is that having a single source of information for the name of an image produced between pack and other platforms would be nice, but the complexity of defining multiple images and what that means for caches and other things might not be justified.

jkutner commented 1 year ago

I'm going to close this for now. But let's revisit after we finalize pack.toml. There may be opportunity to do something more specific to pack (and avoid some of the complications uncovered here)