SRVOCF-1038: Show build status and pipeline failures in the functions list

[matejvasek]

Summary

• 🎁 Surface GitHub Actions build status (Building / BuildFailed, with failure reason and a link to the run) in the functions list
• 🎁 Live updates over SSE (/api/v1/func/build/watch) plus a snapshot endpoint (/api/v1/func/build/status), user-scoped like /list
• 🔧 scm.Client.LatestWorkflowRun via GitHub Actions, scoped to func-deploy.yaml, ETag-cached to keep 304s free against the rate limit
• 🧪 Ginkgo tests (handler, scm/github, fakegithub); Vitest tests (useBuildStatus, list merge); Playwright e2e against the real backend and fakegithub
• 📚 Design spec in docs/design/2026-08-26-SRVOCF-1038-build-status-design.md

Fixes SRVOCF-1038

Checklist

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

Additional Info

• Build status is non-destructive over an available function: Running/ScaledToZero keep their cluster badge with a secondary build indicator, so availability is never misrepresented.
• Deferred: non-destructive treatment for a cluster Error (needs gating on cluster presence, not the status string, since Error is overloaded with a repo/list-level error). Noted in the design doc.
• Draft while the xhigh self-review findings are triaged (no high-severity; remainder are low / prototype-scope).

🤖 Generated with Claude Code

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[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

[matejvasek]

/test all

[matejvasek]

/test e2e-aws

[openshift-ci-robot]

@matejvasek: This pull request references SRVOCF-1038 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:

Summary

• 🎁 Surface GitHub Actions build status (Building / BuildFailed, with failure reason and a link to the run) in the functions list
• 🎁 Live updates over SSE (/api/v1/func/build/watch) plus a snapshot endpoint (/api/v1/func/build/status), user-scoped like /list
• 🔧 scm.Client.LatestWorkflowRun via GitHub Actions, scoped to func-deploy.yaml, ETag-cached to keep 304s free against the rate limit
• 🧪 Ginkgo tests (handler, scm/github, fakegithub); Vitest tests (useBuildStatus, list merge); Playwright e2e against the real backend and fakegithub
• 📚 Design spec in docs/design/2026-08-26-SRVOCF-1038-build-status-design.md

Fixes SRVOCF-1038

Checklist

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

Additional Info

• Build status is non-destructive over an available function: Running/ScaledToZero keep their cluster badge with a secondary build indicator, so availability is never misrepresented.
• Deferred: non-destructive treatment for a cluster Error (needs gating on cluster presence, not the status string, since Error is overloaded with a repo/list-level error). Noted in the design doc.
• Draft while the xhigh self-review findings are triaged (no high-severity; remainder are low / prototype-scope).

🤖 Generated with Claude Code

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.

[openshift-ci]

@matejvasek: 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.

[pmeida]

Side note: Can we have a more accurate message here?
the "Save & Deploy" btn can maybe stay as it is but the message should indicate that clicking it starts a build first, specially now that we have the status

[twoGiants]

Nice! Good work :) 👍

First review batch.

[twoGiants]

The status should be constructed in one place, so we need to gather all we need for it in one place too.

This belongs into useCluster where we get the other data for the status from the cluster and create it via deriveKnativeStatus.

At some point when we migrate the resource watching (useCluster logic) to the backend the full status will be created in the backend and the frontend will only receive the value.

[matejvasek]

For simplicity I could create composite hook, e.g. useFunctions that would call useBuildStatus and useCluster and merge their result.

[matejvasek]

At some point when we migrate the resource watching (useCluster logic) to the backend the full status will be created in the backend and the frontend will only receive the value.

Yeah, exactly. But that's for another time. The PR is already like huge.

[twoGiants]

I think you can drop those. We don't use them anyway.

[twoGiants]

In the current implementation the composite status of a function deployment is separated into two statuses: ClusterFunction.status and BuildStatus. They need to move closer together and become one composite status i.e. the status property needs an overhaul.

It could be done like this:

export interface ClusterFunction {
  readonly name: string;
  readonly namespace: string;
  readonly status: FunctionStatus;
  readonly url: string;
  readonly replicas: number;
  readonly mainResource: K8sResourceCommon;
}

interface FunctionStatus {
  deploymentStatus: DeploymentStatus;
  buildStatus: BuildStatus;
  conclusion?: string;
  runURL?: string;
  failureReason?: string;
}

type DeploymentStatus = 
  | 'Deploying'
  | 'Running'
  | 'ScaledToZero'
  | 'Error'
  | 'Unknown' // <- not sure about this
  | 'NotDeployed';

type BuildStatus = 
  | 'Building' 
  | 'Succeeded' 
  | 'Error'  // <- to be consistent with DeploymentStatus
  | 'None';

// OR THIS
interface FunctionStatus {
  deploymentStatus: DeploymentStatus;
  buildStatus: BuildStatusDetails;
}

type DeploymentStatus = 
  | 'Deploying'
  | 'Running'
  | 'ScaledToZero'
  | 'Error'
  | 'Unknown' // <- not sure about this
  | 'NotDeployed';

interface BuildStatusDetails {
  status: BuildStatus
  conclusion?: string;
  runURL?: string;
  failureReason?: string;

type BuildStatus = 
  | 'Building' 
  | 'Succeeded' 
  | 'Error'  // <- to be consistent with DeploymentStatus
  | 'None';

And the status should be created and updated in one place where the data for it is gathered -> useCluster.

[twoGiants]

This should move to useCluster where ClusterFunction is constructed and then 1 to 1 mapped to FunctionTableItem.

[twoGiants]

Move the func into mergeBuild and remove the comment, it's low value, tha name and the condition says it all.

[twoGiants]

Remove comment.

[twoGiants]

I think a brief comment above the function is enough to explain what happens in this function.

[twoGiants]

I dislike the LLM style speak in the comments.

Suggested change

	// Not currently deployed/available: the build status is the most useful thing
	// to show, so it becomes the primary status.
	// Not currently deployed/available: show only the build status.

[twoGiants]

Move this stub code to sdkTestDoubles.tsx module. I created it to contain all the test doubles for the OCP SDK.

[twoGiants]

You added the owner for using it as a part of the composite key for buildStatus or?

The repo name is unique and would suffice, or?

[matejvasek]

As of now repoName would suffice because we are displaying repos only for currently logged user (currently set PAT owner).

The owner was added mostly to match backend strcutres, and backed was done to match GH API. So it's there more for consistency.

However I think we could display function from various repositories (owners) that given user has access to, so I would keep.

[pmeida]

Nice job!

Also, can we cleanup the comments and only preserve the ones that explain the why? if they are absolutely needed?

[pmeida]

When I click it this kind of border appears. Can we disable this behaviour?

[pmeida]

In a normal non-failing build status 2 appears during a second or two.
This looks like a glitch.

This status appears for more time when its the first build, on function creation, but here it looks weird.

Can we get rid of this status at all? Or at least not allow it to happen in this case?

[pmeida]

IMO we dont need the failureReason.

Saying something like "Latest build failed: deploy / Run tests" doesnt really give me much, I would still have to click on the link and investigate.

Also, this adds complexity when integrating with other building mechanisms other than github actions.

[pmeida]

Nothing to loose on making the in progress spinner also clickable. Users may want to check the in progress build details.

[pmeida]

This has currently no consumer. Did you kept it for debugging?

[pmeida]

Suggested change

	if (event && event !== 'build-status') return null;
	if (event !== 'build-status') return null;

let event = '';
if (event && event !== 'build-status'){ console.log(null)} else {console.log("continue")}

continue

This treats an empty-string event (SSE frame with no event: line) as a valid build-status snapshot.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from twogiants. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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