-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Updates to ko builder design proposal to add implementation approach #6046
Updates to ko builder design proposal to add implementation approach #6046
Conversation
Update resolved questions and add section for implementation approach.
Codecov Report
@@ Coverage Diff @@
## master #6046 +/- ##
==========================================
- Coverage 70.76% 70.55% -0.21%
==========================================
Files 466 468 +2
Lines 17956 18036 +80
==========================================
+ Hits 12706 12726 +20
- Misses 4320 4375 +55
- Partials 930 935 +5
Continue to review full report at Codecov.
|
Add rough steps to Approach section.
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.
one tiny typo and response to a question
4. Should the ko builder be the default for `skaffold init`, instead of | ||
buildpacks, for Go apps, when there's no Dockerfile and no Bazel workspace | ||
file? |
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 think this would be a good option. The way init
treats buildpacks currently is pretty much like a catch all if we can't find a more specific builder to use for the project. So ko would be a good option to use first in this case
Co-authored-by: Marlon Gamez <[email protected]>
Tracking: #6041
Description
Update resolved questions and add section for implementation approach.
Specifically, document that the implementation will be a series of small PRs that can be merged one-by-one, rather than all at once when the feature is done. The PRs will not surface any new user-visible behavior until the feature is ready to be released.