Support user specified entrypoints

[lance]

When a function is deployed to the cluster, the primary entry point is that specified in the buildpack's toml file. For example the following will cause npm start to be the container entrypoint:

cat > "$layersdir/launch.toml" <<EOL
# our web process
[[processes]]
type = "web"
command = "npm start"
EOL

It is possible, however, to support multiple entrypoints both in the buildpack's toml file as well as in a Service deployment. This would be beneficial for supporting a debug deployment. For example, with the following toml, a user could run kn func deploy --debug causing func to set the Service command attribute to debug.

cat > "$layersdir/launch.toml" <<EOL
# our web process
[[processes]]
type = "web"
command = "npm start"

# our debug process
[[processes]]
type = "debug"
# Ensure that dev dependencies are installed
command = "npm install && npm run debug"
EOL
# ...

There are approaches we can take with environment variables that may allow for a quicker implementation of debug support. That may be appropriate for the near term, but long term, I think multiple entrypoint support is more flexible and powerful.

[lance]

https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#notes

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[pseudorandoom]

I'm not super familiar with buildpacks but is this configuration going to be a code block in the func.yaml file that will be copied directly to the toml file? From the use case you mentioned adding a --debug would allow the user to specify the type as in --debug=web => type = "web"? Just wondering how it would support more than two entrypoints or if two is the exact amount you would like to support for this feature

[lance]

@shinigambit the .toml file examples I provided above would be a part of the buildpack so that when the function's deployable image is created, there are multiple image ENTRYPOINTS. By default, the image would be started (in this case) with the web entrypoint. But, if we were to add support for an entrypoint entry in func.yaml, that would allow us to set the entrypoint on the container when it's deployed to (in this case) debug. Ideally, the func CLI would be able to examine the image and validate any user-supplied entrypoint names before deployment.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[zroubalik]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[lance]

/remove-lifecycle stale

[lance]

Now that we have moved to usage of paketo buildpacks across the board, I wonder if this is relevant any longer. In order to support this, we will need to create a func buildpack that runs in addition to the various runtime buildpacks. I'm leaning towards closing this.

[lance]

@knative-sandbox/kn-plugin-func-approvers I am closing this as it seems to be unneeded now.