-
Notifications
You must be signed in to change notification settings - Fork 153
feat: s2i builder with preliminary node support #923
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
feat: s2i builder with preliminary node support #923
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
Needs 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 |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not run a typescript test yet, but I am hopeful as well.
/lgtm |
/hold |
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.
/lgtm
/lgtm |
Changes
--builder=s2i
/kind enhancement
First step towards accomplishing #908