feat: Add Harness integration starter components

[0vertake]

Implements #2998

Summary

This PR adds a new Harness integration to SuperPlane with two starter components:

1. Trigger: harness.onPipelineCompleted
2. Action: harness.runPipeline

The goal is to let users build workflows that react to Harness pipeline completions and start Harness pipelines from SuperPlane.

Connection Method

Chose API key-based integration via Harness REST APIs (x-api-key), with optional org/project scoping for resource listing and execution calls.

For trigger security, added optional webhook secret validation using:

• Authorization: Bearer <secret> (recommended)
• X-Harness-Webhook-Token
• X-Api-Key

What Was Implemented

Backend

• Added new integration package: pkg/integrations/harness/
• Added integration registration in pkg/server/server.go
• Implemented Harness client for:
  • integration verification
  • listing pipelines
  • running pipelines
  • polling execution summary
• Added robust status normalization and terminal-state handling.
• Added bounded polling retry behavior for summary API failures (prevents endless running state).
• Added payload parsing support for real-world Harness webhook/status shapes (completed, nodeStatus, etc.).
• Added example data/output for docs generation.

Components

• On Pipeline Completed (Trigger)
  • Optional pipeline filter
  • Status filters (succeeded, failed, aborted, expired)
  • Emits normalized payload with raw webhook payload included
• Run Pipeline (Action)
  • Pipeline selection from integration resources
  • Optional ref
  • Optional input set references
  • Optional runtime YAML override
  • Polls until terminal state and routes to success/failed outputs

Frontend

• Added Harness workflow mappers in:
  • web_src/src/pages/workflowv2/mappers/harness/
• Wired Harness into mapper registry and integration/icon display maps.
• Added Harness integration icon asset and sidebar/icon wiring.

Docs

• Generated component docs:
  • docs/components/Harness.mdx

Validation Performed

• Unit tests for pkg/integrations/harness pass.
• Manual validation:
  • runPipeline success path
  • runPipeline failure path
  • onPipelineCompleted webhook trigger firing
  • webhook auth behavior (Authorization: Bearer <secret>)
  • pipeline/status filtering behavior
  • input set references behavior
  • runtime YAML override behavior

Demo

• Video 1: https://youtu.be/CyNk7902-V0 (integration setup + runPipeline flow)
• Video 2: https://youtu.be/I2xjR4MG8MA (onPipelineCompleted filters, failure case, input set reference, YAML override)

Notes

• Harness webhook callbacks require a publicly reachable URL (local localhost requires tunneling, e.g. ngrok, during development).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[AleksandarCole]

Hey @0vertake - thanks for opening this one.
I ran it to try it out - but got stuck a bit on the connecting the integration part.

We have a lot of optional things listed there which I understand from the engineering side - but from user side it's confusing a bit.

What is the purpose of the Org Id and Project Id fields?

We have the webhook secret to fill in, but we are providing the webhook URL only once you create a trigger component? Order is a bit confusing.

---

The connection needs to be as simple as possible and automated as much as the tool we're integrating allows.
Does Harness let you just create a webhook via API? We do that for Semaphore integration for example. If they do have that option - we shouldn't rely on user having to configure it manually.

---

All in all, the inexperienced user (me) needs to be able to connect this without too much thinking or digging through the Harness docs and UI. Should be clear an unambiguous - go here, do this.

Alternatively, if it helps, you can start with integration that will work with a single simpler component only (action) and then once we find a good UX pattern - we can extend it to introduce more complexity (trigger and webhook setup).

[0vertake]

Hey @AleksandarCole, thanks a lot for the detailed feedback.

You’re absolutely right that the connection flow currently exposes too many implementation details. Fields like Account ID, Org ID, and Project ID exist because Harness scopes most resources by account → org → project, so the API requires them. But from a user perspective there’s no reason they should have to find and type these manually.

Based on your feedback, I’m planning to simplify the connection flow to something like this:

• API Key
• Org (dropdown, fetched after entering API key)
• Project (dropdown, fetched after selecting org)

Internally I’ll still store the account/org/project identifiers, but they’ll be derived automatically instead of being manual inputs. The Account ID can be fetched directly from the API key, so that field doesn’t need to be visible at all.

I also agree that webhook configuration shouldn’t appear in the connection step. The better flow is to keep the connection minimal and only deal with webhooks when a trigger is created. Harness allows creating webhooks via API. A safe webhook secret would be automatically generated and hidden from the user.

In some accounts the events needed to trigger them (for example pipeline completion events) may not be delivered due to account configuration or feature flags, so I’m planning to implement a polling fallback to ensure the trigger still works. This is mentioned in the Harness documentation around EventRelay generic webhook triggers.

I’ll also add an Advanced section that allows setting a base URL in case users are self-hosting Harness or using a custom domain.

For the Run Pipeline action, I’m also planning to simplify the node UI to reduce cognitive load for new users. The idea is to keep the main flow minimal and move more technical options under Advanced:

Run Pipeline

• Pipeline (dropdown, showing names rather than identifiers)
• Input Sets (optional)

Advanced

• Git Ref (optional, only relevant for Git-based pipelines)
• Runtime Input YAML (advanced override for pipeline inputs)

This should make the common case straightforward while still allowing full control when needed.

For the On Pipeline Completed trigger, I’m also planning to keep the main configuration focused only on trigger conditions (pipeline and statuses), and move less commonly used options like custom run title under an Advanced section to keep the primary setup simple and clear.

Let me know if this direction sounds good!