feat: s2i builder with preliminary node support#923
feat: s2i builder with preliminary node support#923knative-prow[bot] merged 24 commits intoknative:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lkingland The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
db026c6 to
ff8ac0e
Compare
Codecov Report
@@ Coverage Diff @@
## main #923 +/- ##
==========================================
+ Coverage 43.85% 46.07% +2.22%
==========================================
Files 55 56 +1
Lines 5163 7395 +2232
==========================================
+ Hits 2264 3407 +1143
- Misses 2576 3660 +1084
- Partials 323 328 +5
Continue to review full report at Codecov.
|
ea94b47 to
ef8cf90
Compare
da706bd to
9d70e2e
Compare
9d70e2e to
f3a9a55
Compare
|
@lkingland why the changes to the node/go templates? |
Builders are no longer defined in a template's manifest, because a Function can be built with either a Buildpack or an S2I builder, and thus the default is dependant on the builder chosen at build time. These defaults should have been in the code from the beginning, and this is the forcing function. |
I think we had defaults in code and then removed it. |
|
But the defaults are only for embedded templates. We will have to update |
|
@lkingland |
lance
left a comment
There was a problem hiding this comment.
Looks like a great first step into s2i builds. There are some things I think we'll want to consider in the long run, such as how we deal with chained builds (important to avoid having 500MB application images), and perhaps other things of a similar nature. A few questions within, but overall lgtm.
| // DefaultBuilderImages for Pack builders indexed by Runtime Language | ||
| var DefaultBuilderImages = map[string]string{ | ||
| "node": "gcr.io/paketo-buildpacks/builder:base", | ||
| "go": "gcr.io/paketo-buildpacks/builder:base", |
There was a problem hiding this comment.
This won't really work for Go functions though, will it? They need the scaffolding that is in the buildpack as well, right?
There was a problem hiding this comment.
It is my understanding that the base is the same, but the buildpack builder will still apply any buildpacks defined, which include ghcr.io/boson-project/go-function-buildpack:tip, which has the scaffolding. The S2I builder, when updated to support Go, will of course ignore that and use its own method, which I presume will be a single builder image that includes everything required.
There was a problem hiding this comment.
It is my understanding that the base is the same, but the buildpack builder will still apply any buildpacks defined, which include
ghcr.io/boson-project/go-function-buildpack:tip, which has the scaffolding.
Yes, this is the case, if it is explicitly provided, for example in a func.yaml file in the buildpacks field. Is that what you are expecting? Without that, the scaffold isn't there.
|
|
||
| cmd.Flags().StringP("builder", "b", "", "Buildpack builder, either an as a an image name or a mapping name.\nSpecified value is stored in func.yaml for subsequent builds.") | ||
| cmd.Flags().StringP("builder", "b", "pack", "builder to use when creating the underlying image. Currently supported builders are 'pack' and 's2i'.") | ||
| cmd.Flags().StringP("builder-image", "", "", "builder image, either an as a an image name or a mapping name.\nSpecified value is stored in func.yaml for subsequent builds. ($FUNC_BUILDER_IMAGE)") |
There was a problem hiding this comment.
It strikes me as clumsy that there is both a builder and build-image flag. I wonder if it should rather be something like strategy and build-image (or build), where strategy is a fixed set (buildpack, s2i, etc) and build-image or build is an image address.
There was a problem hiding this comment.
I agree. We should try to consolidate this a little bit. I wouldn't block this PR on this though. But it is something we should try to tackle as soon as possilbe. To provide consistency and more clarity for users.
There was a problem hiding this comment.
In order to not block this PR, I have opened a new issue to discuss better flag naming: #942
| return errors.New("Unable to build via the s2i builder.") | ||
| } | ||
|
|
||
| builder, _, err := strategies.Strategy(client, cfg, build.Overrides{}) |
There was a problem hiding this comment.
Am I correct to understand this is the "docker" build strategy? One of the other build strategies that s2i uses is "binary" which we may consider leveraging for push-to-cluster-my-function-and-build-it-there, since that's exactly what it does.
There was a problem hiding this comment.
Yes, it is my understanding this is the Docker method. I am not familiar with the binary strategy, but I will look into it.
| ) | ||
| defer cleanup() | ||
|
|
||
| run(t, bin, prefix, "create", "-v", "--language=node", cwd) |
There was a problem hiding this comment.
Did you test with typescript? I don't know if s2i can seamlessly do that or not, but it sure would be nice
There was a problem hiding this comment.
I have not run a typescript test yet, but I am hopeful as well.
|
/lgtm |
|
/hold |
|
/lgtm |
Changes
--builder=s2i/kind enhancement
First step towards accomplishing #908