SRVOCF-979: return union of repo and cluster functions

[pmeida]

Summary

• /func/list now returns the union of GitHub repo-discovered functions and cluster-deployed functions, each tagged with a source (repo or cluster); when a function exists in both, repo wins. Cluster-deployed functions with no source repository now appear in the UI.
• Split cluster access by intent: new functions package (unified knative/func facade: the growable functions.Client for cluster queries, plus offline source/CI scaffold generation - the former scaffold package folded in so all knative/func usage sits behind one boundary) and new kube package (shared REST config: host resolution, TLS, JSON content type, request timeout). cluster is now provisioning-only (RBAC, service accounts, tokens) instead of a god-client.
• Frontend threads source through the table, disables Edit for cluster-only functions with a tooltip ("No source repository to edit"), and renders empty runtime as a dash.
• Bumped knative/func to include fix(list): populate RUNTIME column in func list knative/func#4010 so cluster-deployed functions report their runtime and refactor(listers): inject k8s.Client via DI knative/func#4003 so that we can inject rest configs into the lister.
• Added backend specs for the union/merge and the functions package; added frontend tests for cluster-only rows and the disabled-Edit behavior.
• Documented the kube/functions packages and the cluster-access split.
• Dropped the redundant direct go.yaml.in/yaml/v3 dependency, using sigs.k8s.io/yaml for func.yaml parsing

Fixes SRVOCF-979

Checklist

• Updated docs/ARCHITECTURE.md (if there are relevant changes to our layered architecture)

Additional Info

Reasoning for the design decisions:

• cluster (write: provisioning) and functions (function lifecycle) answer different questions, so they are separate packages rather than one shared client interface. functions.Client is an interface (not a bare lister) because deploy/delete/describe may be expected next.
• Shared connection logic lives in kube.RESTConfig, a leaf package (depends only on client-go/rest), so both domain packages build connections identically without a dependency cycle. It intentionally does not live in config, which is the wiring layer imported only by handler/main.
• Graceful degradation on cluster list failure: repo-discovered functions are the required result; cluster-deployed functions are an enrichment. If connecting to the cluster or listing functions fails (knative not installed, RBAC forbidden, API unreachable), the handler logs a warning and returns the repo-sourced list rather than failing the request. Only a repo/SCM failure is fatal (401 on an invalid token, 502 otherwise). Cluster results add to the picture; they do not gate it.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pmeida

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [pmeida]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@pmeida: This pull request references SRVOCF-979 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.1.0" version, but no target version was set.

Details

In response to this:

What

/func/list now returns the union of GitHub repo-discovered functions and cluster-deployed functions, instead of sourcing the list from GitHub repositories alone. Each item carries a source (repo or cluster); when a function exists in both, the repo source wins.

Jira: SRVOCF-979

Why

Functions deployed to the cluster without a discoverable source repository never showed up in the UI. This makes the list reflect what is actually deployed as well as what is editable from source.

Backend

• New functions package exposing a growable functions.Client facade over knative/func (only List today; deploy/delete/describe expected next).
• New kube package owning the shared REST config (host resolution, TLS, JSON content type, default request timeout); both cluster and functions build connections through it.
• cluster is now provisioning-only (RBAC, service accounts, tokens); function querying moved out of the cluster client so it is no longer a god-client.
• List handler merges repo + cluster results, keeping repo when a function is present in both.
• Bumped knative/func to include fix(list): populate RUNTIME column in func list knative/func#4010 so cluster-deployed functions report their runtime.

Frontend

• Added FunctionSource type, threaded source through the table.
• Edit is disabled for cluster-only functions, with a tooltip explaining there is no source repository to edit.
• Empty runtime now renders as a dash, matching url/namespace.

Docs

• docs/ARCHITECTURE.md documents the kube/functions packages and the cluster-access split.

Testing

• Backend: go build, go vet, go test ./..., golangci-lint all green.
• Frontend: vitest function-list suites pass (38 tests).

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[pmeida]

Edge cases in the repo/cluster function union - worth discussing

This PR merges repo-discovered and cluster-deployed functions, which surfaces two states we should be intentional about:

1. Function on the cluster but no repo (source: cluster)
   The function is listed but not editable, since we don't have its source. This can happen when:

   • the user deployed it directly with the func CLI
   • the backing repo was deleted
   • the repo exists but isn't visible to the provided token.
     Current behavior: Edit is disabled with a generic "No source repository to edit" tooltip. That's reasonable, and from the console's vantage point these three sub-causes are indistinguishable, so I don't think we can do better here.

2. Function has a repo but isn't on the cluster (source: repo)
   The row shows NotDeployed. But that single badge collapses several different situations:

   • not deployed yet
   • the deploy workflow failed
   • it's deployed on a different cluster and only shows up here because the same SCM token for both clusters

   Should we distinguish these? The "workflow failed" case is detectable (we already hold the SCM token and could query the GitHub Actions run status) - I think we have a ticket for it. "Deployed on another cluster" is not reliably detectable from the current cluster. At minimum, wording like "Not deployed on this cluster" would be more honest than "NotDeployed".
   Deploy action: there's currently no way to deploy a repo-only function from the console. Do we want one (e.g. triggering the existing CI workflow via workflow_dispatch)? Probably out of scope for this PR.

[pmeida]

/test e2e-aws

[pmeida]

/test e2e-aws

[pmeida]

/test e2e-aws

[twoGiants]

remove, we have sigs.k8s.io/yaml v1.6.0 in line 16

[pmeida]

Done.

Notice that sigs.k8s.io/yaml is itself a wrapper around go.yaml.in/yaml/v3. So by switching to it, we still pull that package in transitively (indirect section)

[twoGiants]

It makes sense to have an adapter for functions pkg.

I think scaffold could be merged into here. The scaffold package is basically the C in CRUD for function management and the functions package is now the R.

[pmeida]

284263f

[pmeida]

/test e2e-aws

[openshift-ci]

@pmeida: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.