-
Notifications
You must be signed in to change notification settings - Fork 293
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
Allow pack buildpack package to create buildpackages without package.… #1103
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1103 +/- ##
==========================================
- Coverage 80.53% 79.99% -0.53%
==========================================
Files 136 136
Lines 8233 6002 -2231
==========================================
- Hits 6630 4801 -1829
+ Misses 1174 767 -407
- Partials 429 434 +5
Flags with carried forward coverage won't be shown. Click here to find out more. |
Acceptance NotesSetupused the following buildpacks
Build this sample app using the above buildpacks. Outputa successfully built image 👍 ConclusionThis looks great! |
cmd.Flags().StringVarP(&flags.Format, "format", "f", "", `Format to save package as ("image" or "file")`) | ||
cmd.Flags().BoolVar(&flags.Publish, "publish", false, `Publish to registry (applies to "--format=image" only)`) | ||
cmd.Flags().StringVar(&flags.Policy, "pull-policy", "", "Pull policy to use. Accepted values are always, never, and if-not-present. The default is always") | ||
cmd.Flags().StringVarP(&flags.Buildpack, "buildpack", "b", "", "Path to the Buildpack that needs to be packaged. If config is specified, the Buildpack URI is overridden to this value.") |
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.
Some questions about why this flag is necessary.
Could we not just rename config
to path
and be able to provide a directory, buildpack.toml, or package.toml file?
I'm also concerned by it's behaviour "if config is specified, the buildpack URI is overriden". What's the use case in mind?
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.
Don't think I had a particular use case in mind. I tried to replicate the behavior that was specified in the issue. Should buildpack and config be mutually exclusive?
Also re:path, are there use cases where we would want to specify a path to the buildpack.toml instead of the buildpack dir? And for distinguishing the use case, should we just provide a path to a folder in general? if that contains a package.toml that would be picked, otherwise it would treat it like a folder with buildpack.toml, would this behavior work?
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.
Don't think I had a particular use case in mind. I tried to replicate the behavior that was specified in the issue. Should buildpack and config be mutually exclusive?
Ah, I see "If --buildpack
and --config
are provided, --buildpack
should take precendence over buildpack.uri
in package.toml
.". @ekcasey what's the thought behind that?
Would supporting multiple reference types using one flag support the desired use cases (while keeping a sensible UX)?
I'm thinking of pack build ... --path
where path can be a path to a jar
file that then gets treated as source code.
In this particular case --path
may be:
- a buildpack directory (in that directory we can search for a
package.toml
first, then abuildpack.toml
) - a
package.toml
file - a
buildpack.toml
file
If we do end up deciding to go with --path
, then I would think we would deprecate --config
/-c
which feels sort of wrong as well. Thoughts?
Related: #932
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 would prefer to keep it to a directory only instead of accepting paths to specific toml files. That way the input to the path config variable is consistent. It should then be upto pack to determine how to package the given directory. If it contains package.toml use that. If it contains buildpack.toml that is valid and can be standalone, it should be able to figure out the default package.toml (which is the behavior in this PR). And by default this path variable will be the current dir. This will make it consistent with something like pack build. Thoughts?
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.
The reason why I proposed supporting pointing to files is because I don't think we should restrict what those files should be named. Could there be use cases for multiple flavors of a package.toml
?
package.stack-a.toml
- packaging information specific for stack-a.package.stack-b.toml
- packaging information specific for stack-b.
My example is pretty edgy but I think it's a principle of not forcing a filename that is important to me. Whether that's a shared sentiment or we feel is worth the trade off is up for debate.
Stepping back a little bit the alternative isn't bad either.
Let me try to summarize the options:
Option 1: --path
for all
- Support
--path
to point to any of the following:- a buildpack directory
- a
package.toml
-formatted file - a
buildpack.toml
file
- When a directory is provided, search for
package.toml
, if not found fallback tobuildpack.toml
(Use a default package config for a buildpackage #932 behaviour) - Deprecate
--config
flag
Option 2: --config
for project.toml
, --path
for buildpack dir
- Support
--config
to point to a specificpackage.toml
-formatted file - Support
--path
to point to a specific buildpack directory - Make
--config
and--path
mutually exclusive - When
--path
is provided, search forpackage.toml
, if not found fallback tobuildpack.toml
(Use a default package config for a buildpackage #932 behaviour)
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.
That makes sense, I never realized that package.toml was not a special file per the spec. I have a couple of questions WRT Option 1 - how will we detect if the given path is a package.toml file or not if it can be named something other than package.toml? If that is a usecase we wish to support then it might be easy to provide support for option #2. Thoughts?
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.
The buildpack.uri
field in package.toml
also supports a tarball buildpack file. Can we support that as well?
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.
Based on our conversation during Sub-Team Sync, we are circling around Option 2 as the prefered method to eliminate the added complexity needed to detect project.toml
vs buildpack.toml
.
@ryanmoran, that sounds like a great idea. We'd probably want to punt that into a separate following issue though.
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.
Should be all done now - the flag has been renamed to --path and it has been made mutually exclusive to --config
…toml for component buildpacks Signed-off-by: Sambhav Kothari <[email protected]>
✅ Accepted
|
…toml for component buildpacks
Summary
This change allows users to create buildpackages without a package.toml
It follows the behavior specified in #1082
i.e.
If no package.toml is specified -
it uses the current dir as the buildpack dir
if
--path
is specified it uses that dirif both are specified it returns an error saying that their usage is incompatible together
Output
Before
After
Documentation
Related
Resolves part of #1082