knative
On-cluster build: Support for build on cluster only "func build --remote"
It would be good, especially in the development phase of a function, to have the ability to build the function on the cluster only, without deploying it, using func build --remote, similar to func deploy --remote.
Yes this would be a nice to have. Just to add to this discussion a bit, the flag permutation func deploy --remote --build=false may be something we want to open a separate issue for as well, which would do the opposite, deploy the given image without rebuilding.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi @zroubalik, @matejvasek: I was working on this function yesterday, but I noticed that depending on the implementation of PipelineProvider, the way the pipeline is built is different (imperative or as PAC) and both variants are currently actively used in the code. My plan was to reuse the current implementation and just skip the deploy-Task in case of using func build --remote. Do I need to provide this functionality for both variants as well (where afaik the PAC solution is currently used for configuration with Git only)? What is the plan for the PAC solution (it is relatively new, since March this year)? Do we deprecate the imperative way soon? Please share your opinion and advice. Thx.
@zroubalik, @matejvasek Hi fellows, is there any update to my question above? Since this function is actually for testing purposes, I think I will implement it imperatively (means no PAC) and decline to use it if it is used with the git configuration. What do you think about this?
As there are no updates to my above questions I will implemented it as proposed (only imperative version, no PAC), as I need it to process with https://github.com/knative/func/issues/984
Came across this struggling to get started with Knative. Quick summary of my experience:
- Windows/WSL2 pretty much forces remoting
- Remoting than requires Tekton
- Docs are disjoined. https://knative.dev/docs/functions/building-functions/#prerequisites_1 links to the func main page, where unreleased changes do not include the Tekton configuration instructions for v1.10.
- any func remote commands result in
unable to decode an event from the watch stream: unable to decode watch event - tekton pipeline fails but still publishes the container image.
This would go a long way for troubleshooting individual pieces instead of needing to debug everything at once.
@zroubalik @matejvasek The reason for this issue is the need to be able just to build and push a function on cluster without deploying it, like this func build --remote. It would be very useful in case of testing of the remote behaviour.
The idea here it to reuse the function generatePipeline from pkg/pipelines/tekton/resources.go by modifying the creation process. Currently there is a simple line there, creating fixed pipeline with two tasks:
// ----- Pipeline definition
tasks = append(tasks, taskBuild, taskDeploy(taskNameBuild))
Is there in your opinion any elegant way to check the "caller context" so that we can have something like this (pseudo code):
switch callerCtx := getCallerCtx(); callerCtx {
case "build":
tasks = append(tasks, taskBuild)
case "deploy":
tasks = append(tasks, taskBuild, taskDeploy(taskNameBuild))
}
Or the whole idea does not make any sense, because of the code structure... Thx in advance.
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.
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.
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.