Related Pages

Related topics: System Architecture, Auth, and Code Hosting (Repos, PRs, Webhooks), CI/CD Pipelines: Execution, Runners, and Triggers, Gitspaces (Cloud Dev Environments) & Artifact Registry

Overview, Setup, and Running Harness Locally

1. Project Overview

Harness (historically known as Drone, and currently packaged under the binary name gitness) is an open-source, container-native continuous integration and delivery platform. The harness/harness repository contains the central server that coordinates source-control webhooks, schedules builds on remote agents, exposes a web UI and HTTP API, and persists build state.

The main entry point wires every component together at startup:

• It registers HTTP routes, the build scheduler, the logging subsystem, and the source-control adapters.
• It loads configuration exclusively from environment variables; there is no in-process config file parser.
• It exits non-zero on fatal startup errors, which makes it friendly to process supervisors and to the local make targets described below.

Source: cmd/gitness/main.go:1-80 Source: README.md:1-40

2. Prerequisites

Before bringing the server up locally, prepare the following toolchain and accounts:

Source: Dockerfile:1-40 Source: Makefile:1-60

3. Local Configuration

Configuration is driven by environment variables. The repository ships a checked-in template called .local.env that captures every variable required to boot the server with sensible development defaults. To use it:

1. Copy the template: cp .local.env .env.
2. Fill in the secrets — at minimum the source-control client ID/secret, an RPC secret shared with any agent, and a cookie signing secret.
3. Source it into your shell (set -a; source .env; set +a) or pass it to docker compose.

Important variables present in .local.env:

• DRONE_GITHUB_CLIENT_ID / DRONE_GITHUB_CLIENT_SECRET — OAuth credentials registered against your SCM.
• DRONE_RPC_SECRET — shared HMAC secret between server and agent.
• DRONE_SERVER_HOST / DRONE_SERVER_PROTO — public URL the server advertises in callbacks.
• DRONE_DATABASE_DATASOURCE — DSN pointing at SQLite (default) or an external database.

Source: .local.env:1-80

The cli/cli.go file enumerates the same variables through structured CLI flags, so the same configuration can be supplied on the command line when launching the binary directly with go run.

Source: cli/cli.go:1-120

4. Running the Server

There are three supported ways to run Harness locally, in increasing order of fidelity to production:

4.1 Run from source

make build
./bin/gitness

The build target compiles cmd/gitness into ./bin/gitness and then starts it with the environment exported from .local.env. This mode is fastest for inner-loop development because it avoids image rebuilds.

Source: Makefile:20-80

4.2 Run via Docker Compose

docker compose up --build

The docker-compose.yml file brings up the server container alongside any optional services declared in the file (for example, a local agent or a database). It mounts the same .local.env so that OAuth and RPC secrets stay consistent between the on-host and in-container runs.

Source: docker-compose.yml:1-60

4.3 Run the published image

docker run --rm -p 8080:8080 --env-file .local.env harness/gitness:latest

This is the closest approximation to a production deployment and is the recommended baseline when validating release candidates.

Source: Dockerfile:30-60

5. Verifying the Installation

Once the server is up, confirm health by:

• Hitting http://localhost:8080/healthz — the HTTP handler is registered in the server bootstrap and returns 200 when the database and scheduler are reachable.
• Logging in through the OAuth redirect; the first user to authenticate is promoted to administrator, which is critical for subsequent setup of repositories and secrets.
• Triggering a build by pushing to a repository that has the local server installed as an application or webhook target.

If builds fail to schedule, the most common cause is an DRONE_RPC_SECRET mismatch between the server and the agent — a recurring friction point noted by users in the community discussion around agent connectivity. Feature work such as auto-cancellation of superseded builds (#1980) and additional pull-request events (#1878) assumes this baseline is healthy.

Source: app/server/server.go:1-80 Source: cmd/gitness/main.go:60-140

6. Useful Make Targets

The Makefile is the single source of truth for development commands. The most commonly used targets are:

• make build — compile the binary.
• make test — run the unit test suite (relevant to issue #1021, which discusses reporting changed files to scope the test run).
• make lint — run static analysis.
• make clean — remove build artifacts.

Source: Makefile:1-120

Related Pages

Related topics: Overview, Setup, and Running Harness Locally, CI/CD Pipelines: Execution, Runners, and Triggers

System Architecture, Auth, and Code Hosting (Repos, PRs, Webhooks)

1. High-Level System Architecture

Harness CI is a container-native continuous delivery platform whose server is composed of a thin HTTP layer backed by a service/repository model and a set of pluggable source code management (SCM) drivers. The HTTP boundary is mounted by app/router/api_router.go, which assembles middleware and routes for both user-facing APIs and SCM webhooks. The router delegates every request to a controller in app/api/controller/, where business rules live. Persistent state (users, repos, builds, secrets, cron jobs) is encapsulated in service/, while SCM-specific I/O is isolated behind plugin/scm/ so the server can talk to GitHub, GitLab, Bitbucket, Gitea, Gogs, and others through a common interface.

The request flow is uniform: a request enters the router, traverses session and authorization middleware, reaches a controller, and finally calls the SCM driver for external operations (listing branches, opening/closing PRs, posting commit statuses). This separation is what enables the same controller code to serve multiple code hosts.

flowchart LR
  Client[Client / SCM] -->|HTTPS| Router[app/router/api_router.go]
  Router --> MW[Middleware<br/>session, authz]
  MW --> Ctl[Controller<br/>repo/pullreq/build]
  Ctl --> Svc[service layer]
  Ctl --> SCM[plugin/scm/* driver]
  SCM -->|REST/GraphQL| Host[GitHub/GitLab/Bitbucket]
  SCM -->|webhook delivery| WH[server/webhook]
  WH --> Ctl

2. Authentication and Authorization

Authentication and authorization are split into two cooperating packages: app/auth/authn/ (who is the caller) and app/auth/authz/ (what are they allowed to do).

• app/auth/authn/authenticator.go defines the Authenticator interface used by the API router to resolve a session token (cookie or bearer) into a Principal. Concrete implementations cover session-backed login, signed JWTs, and shared-secret agents. Source: app/auth/authn/authenticator.go:1-80.
• app/auth/authz/authz.go defines the Authorizer interface, with methods such as Authorize(ctx, action, resource) used inside controllers to gate write operations on repositories, secrets, and builds. Source: app/auth/authz/authz.go:1-90.
• app/api/auth/auth.go wires those interfaces together and exposes a Gin middleware that injects the authenticated principal and a per-request authorization helper into the request context. Source: app/api/auth/auth.go:1-60.

The router enforces this for all /api/* routes registered in app/router/api_router.go, and the same middleware stack is reused for webhook endpoints, where the caller is replaced by an SCM-signed payload verifier rather than a user session.

Community issue #2422 ("GitHub Application support") is directly relevant here: adding GitHub App authentication is largely an exercise in adding a new Authenticator that resolves a user from a GitHub App installation token, and a new SCM client in plugin/scm/github/ that uses that token instead of an OAuth user token. The current plugin/scm/github/github.go driver uses an OAuth access token bound to a user, which limits Drone to events and APIs that user tokens can reach (notably, GitHub Checks). Source: plugin/scm/github/github.go:1-60.

3. Code Hosting: Repos, Pull Requests, and SCM Drivers

Repositories are the central aggregate. app/api/controller/repo/controller.go exposes CRUD-like endpoints (POST /api/user/repos, GET /api/user/repos, GET /api/repos/:owner/:name, POST /api/repos/:owner/:name, DELETE /api/repos/:owner/:name). Each endpoint performs three jobs:

1. Validate the caller via auth.Authorize.
2. Call into the SCM driver to verify access and read metadata (default branch, permissions, visibility).
3. Persist a Repo row in the datastore with the SCM credential referenced.

The pull-request controller at app/api/controller/pullreq/controller.go provides read endpoints for listing and inspecting pull requests (GET /api/repos/:owner/:name/pulls, GET /api/repos/:owner/:name/pulls/:number). Because all SCM interaction is delegated to the driver, the controller code is host-agnostic; only plugin/scm/<host>/<host>.go knows how to map these calls to REST or GraphQL. Source: app/api/controller/pullreq/controller.go:1-80.

The SCM plugin layer is the place where behavior that the community has asked about lives. For example:

• Issue #1021 ("Report files changed to limit testing scope") requires exposing the set of files modified in a commit or PR through the SCM driver interface so that downstream build steps can skip work.
• Issue #1878 ("Support additional pull request actions") is constrained by which PR events each SCM emits and which the current SCM driver translates into Drone's internal Event enum (push, pull_request, tag, deploy, promote, rollback).

4. Webhook Processing

Webhooks are the trigger for almost every build. The server registers /hook on every SCM, and server/webhook/webhook.go provides the entry point. When a webhook arrives:

1. The router selects the SCM-specific verifier (signature header, shared secret, or HMAC) implemented inside the SCM plugin.
2. The verified payload is normalized into a Drone Hook struct (event type, repo, ref, commit, author, changed files, action).
3. The hook is matched against enabled repositories; matched repos queue builds through the build controller.

Because the verifier and the payload parser both live in the SCM plugin, adding a new SCM (or new event types from an existing one, as requested in #1878) is a localized change in plugin/scm/<host>/. Source: server/webhook/webhook.go:1-90.

The plugin/handler/handler.go package is the other side of the contract: when a build finishes, the server calls back into the SCM driver to update commit status, post comments, or close/reopen pull requests. This is what enables PR-driven workflows (e.g., "deploy on open, tear down on close" from #1878) — the action parameter on the incoming webhook is preserved on the build and replayed through the handler when the build completes. Source: plugin/handler/handler.go:1-70.

5. Summary

The architecture intentionally separates routing (app/router/), authentication (app/auth/, app/api/auth/), business logic (app/api/controller/), and SCM integration (plugin/scm/). New community-requested features — GitHub App login, richer PR events, files-changed reporting, auto-cancel of superseded builds (#1980) — each map cleanly onto one of these layers, which is why most discussions converge on extending the SCM plugin interface and the authn/authz packages rather than the controllers themselves.

Related Pages

Related topics: System Architecture, Auth, and Code Hosting (Repos, PRs, Webhooks), Gitspaces (Cloud Dev Environments) & Artifact Registry

CI/CD Pipelines: Execution, Runners, and Triggers

Overview and Scope

Harness (Drone) implements its CI/CD pipeline subsystem as a set of cooperating services under app/pipeline/. The subsystem is responsible for converting source-controlled configuration (.drone.yml) into an in-memory model, queuing build work, executing steps on remote agents, and reacting to repository events that should kick off a new build. The major components are the manager (model and persistence), the scheduler (queue and dispatch), the runner (agent-side execution), the triggerer (event-driven starts), and the converters (JSONnet/Starlark preprocessors that expand configuration before scheduling).

Source: app/pipeline/manager/manager.go Source: app/pipeline/scheduler/scheduler.go

Pipeline Lifecycle and the Manager

The manager owns the canonical *Build and *Stage objects and persists them to the database. It exposes create/read/update operations used by the HTTP API and by internal services such as the scheduler and triggerer. When a webhook arrives, the manager records a pending build, attaches the parsed pipeline stages, and transitions the build through states such as pending, running, and complete.

The manager is also the entry point for user-driven actions: restart, cancel, approve, decline, and promote. Cancel and approve paths are commonly exercised by the runner and triggerer; cancel was specifically requested by users as "Builds auto cancellation" to free CI resources when new commits supersede in-flight builds (see community issue #1980).

Source: app/pipeline/manager/manager.go

Configuration Conversion (JSONnet and Starlark)

Before a build is scheduled, the raw .drone.yml is passed through a converter. Harness ships two pluggable converters:

• JSONnet — compiles Jsonnet into YAML using the standard library bundled with the binary, allowing templating and parameterization of pipelines. Source: app/pipeline/converter/jsonnet/jsonnet.go
• Starlark — evaluates Starlark (a Python-like configuration language) so that pipelines can be generated programmatically. Source: app/pipeline/converter/starlark/starlark.go

The converted output is then fed to the manager which validates and persists the resulting stages. The community has discussed adding higher-level "syntactic sugar" such as a top-level cache: shortcut (issue #2060); such conveniences are typically implemented as converters or transform helpers before the pipeline reaches the scheduler.

Scheduling and Execution: Scheduler → Runner

The scheduler maintains an internal work queue of stages awaiting an available agent. It polls the database for pending and approved builds, claims stages, and dispatches them to runners over gRPC. The scheduler enforces ordering (dependencies between stages), timeouts, and capacity limits per repository.

Source: app/pipeline/scheduler/scheduler.go

The runner is the server-side counterpart that lives on the agent host. It receives a stage descriptor, pulls the source tree, prepares the workspace, and starts the step container (Docker or exec runtime). As steps execute, the runner streams logs back to the server, updates the build state via the manager, and reports final status. Cancellation, timeout enforcement, and log truncation all happen here.

Source: app/pipeline/runner/runner.go

A simplified request flow looks like:

flowchart LR
  Webhook[SCM Webhook] --> Triggerer
  Triggerer --> Manager
  Manager --> Scheduler
  Scheduler -->|gRPC stage request| Runner
  Runner -->|state updates| Manager
  Manager -->|events| UI[UI / API]

Triggerers and Event Filtering

The triggerer subscribes to repository webhooks and repository polling and decides whether an incoming event should produce a new build. It evaluates conditions such as branch filters, event types (push, pull_request, tag, promote, rollback), and path filters. The triggerer calls back into the manager to record the build and then notifies the scheduler.

Source: app/pipeline/triggerer/trigger.go

The community has long requested additional pull-request lifecycle events such as closed and merged (issue #1878). These events are handled inside the triggerer: today only opened, synchronize, and reopened typically create builds, while closed/merged are ignored at the trigger step. Adding them requires extending the event-matching logic in trigger.go plus the corresponding UI affordances in app/views/.

Another frequently requested enhancement is exposing the list of files changed in a push so users can scope their pipeline (issue #1021). The triggerer is the natural home for that change, since the SCM webhook payload already carries the changed-files list before a build is created; the data can be attached to the build record in the manager and consumed by converters.

GitHub App Authentication

GitHub integration originally used OAuth Apps; the community has asked for full GitHub App support (issue #2422), which unlocks Checks API access and finer-grained permissions. Although the GitHub integration code lives outside app/pipeline/, it affects the triggerer because GitHub App webhooks use a different authentication flow and event payload structure than OAuth webhooks. Adopting GitHub Apps therefore requires changes to the triggerer's event parser as well as to the runner's source checkout step (which must install a per-installation token).

Putting It Together

A typical pipeline execution follows these stages:

1. Convert .drone.yml via JSONnet or Starlark into a normalized YAML pipeline. Source: app/pipeline/converter/jsonnet/jsonnet.go
2. Trigger — the triggerer matches the SCM event and creates a build. Source: app/pipeline/triggerer/trigger.go
3. Manage — the manager persists build/stage records and transitions states. Source: app/pipeline/manager/manager.go
4. Schedule — the scheduler assigns stages to available runners. Source: app/pipeline/scheduler/scheduler.go
5. Run — the runner executes each step, streaming logs and reporting completion. Source: app/pipeline/runner/runner.go

Understanding these five components is the foundation for any deeper work on Harness CI/CD — whether the goal is auto-cancelling stale builds, supporting new SCM events, reporting changed files, or adopting GitHub Apps for richer Checks integration.

Related Pages

Related topics: Overview, Setup, and Running Harness Locally, System Architecture, Auth, and Code Hosting (Repos, PRs, Webhooks)

Gitspaces (Cloud Dev Environments) & Artifact Registry

Overview and Purpose

Gitspaces is the Harness module that provisions and manages Cloud Development Environments (CDEs) — containerized, on-demand developer workspaces that pair a remote compute instance with a chosen IDE (e.g., VS Code, JetBrains, Jupyter). The module sits inside the Harness application server and orchestrates the full lifecycle: creating an instance, pulling the IDE image, resolving run arguments, attaching the user's repository, and tearing the environment down when finished.

Gitspaces rely on an Artifact Registry abstraction to pull IDE and dev-environment container images, and on an Infra Provider abstraction to allocate the underlying compute (Docker host, Kubernetes cluster, VM, or Harness Cloud). These two abstractions keep the orchestrator engine-agnostic: the same logic works whether the user targets a local Docker daemon, a k8s cluster, or Harness's own cloud. Source: app/services/gitspace/gitspace.go (service entry point wiring the orchestrator, infra provider, and artifact store).

High-Level Architecture

The Gitspaces flow is layered: an HTTP/API controller accepts a request, the service layer applies business rules, and the orchestrator drives the actual container/IDE lifecycle on the chosen infra provider.

flowchart LR
    Client[Client / API] --> Controller[app/api/controller/gitspace]
    Controller --> Service[app/services/gitspace]
    Service --> Orchestrator[app/gitspace/orchestrator]
    Orchestrator --> Container[container_orchestrator.go]
    Orchestrator --> IDEFactory[ide/factory.go]
    Orchestrator --> RunArgs[runarg/resolver.go]
    Container --> Infra[app/services/infraprovider]
    IDEFactory --> Artifact[Artifact Registry]
    Infra --> Target[(Docker / k8s / VM / Harness Cloud)]
    Artifact --> Images[(IDE & dev-env images)]

Source: app/api/controller/gitspace/controller.go, app/services/gitspace/gitspace.go, app/gitspace/orchestrator/container/container_orchestrator.go.

Core Components

Container Orchestrator

The container orchestrator is the heart of the system. It performs the end-to-end sequence: pulling the IDE image, creating the dev container, mapping the user's repository, and exposing ports for the remote IDE connection. It delegates low-level container calls to the Infra Provider so the same orchestrator code path works across Docker, Kubernetes, VMs, and Harness Cloud. Source: app/gitspace/orchestrator/container/container_orchestrator.go.

Because the orchestrator is engine-agnostic, adding a new infra target (e.g., a new cloud VM provider) only requires a new InfraProvider implementation — the orchestrator itself does not change.

IDE Factory

The IDE factory resolves which IDE image and configuration to launch. Given a user's requested IDE type, the factory returns the appropriate image identifier and the IDE-specific bootstrap parameters. This indirection allows new IDEs to be added without modifying the orchestrator's core flow. Source: app/gitspace/orchestrator/ide/factory.go.

Run-Arg Resolver

The run-arg resolver computes the final container launch arguments — volumes, environment variables, port mappings, working directory, and the IDE command. It merges static defaults, user-supplied overrides, and infra-specific values. This component ensures that a Gitspace launched on Docker gets the same user-facing configuration as one launched on k8s. Source: app/gitspace/orchestrator/runarg/resolver.go.

Infra Provider

The infra provider is the abstraction over the compute plane. It exposes a small surface (create/list/start/stop/delete container or VM) and is implemented per environment. The orchestrator depends only on this interface, which is what allows Gitspaces to run on Harness Cloud as well as on user-managed Docker hosts or clusters. Source: app/services/infraprovider/infraprovider.go.

Service and Controller Layers

The Gitspace service coordinates the request across the orchestrator, infra provider, and artifact store, handling persistence, authorization, and state transitions. The controller exposes HTTP endpoints to trigger create/start/stop/delete operations and returns the connection metadata (URL, token) the client uses to attach the IDE. Sources: app/services/gitspace/gitspace.go, app/api/controller/gitspace/controller.go.

Artifact Registry Role

The Artifact Registry supplies container images to the orchestrator — primarily the IDE image (e.g., code-server, jb-gateway) and the dev-environment base image. The registry is consumed indirectly: the IDE factory and orchestrator ask for an image by reference, and the registry handles authentication, pull, and caching. This mirrors the pattern used elsewhere in Harness (CI builds, Drone runners) where image pull is a separate, pluggable concern rather than being hard-coded into the orchestrator.

Operational Notes

• Lifecycle states — Gitspaces transition through create → running → stopped → (optionally) deleted; the controller and service track these states and the infra provider carries them out on the target environment.
• Connection — Once a container is up, the controller returns the access endpoint and credentials so a thin client (browser-based VS Code, JetBrains Gateway, etc.) can attach to the running IDE.
• Extensibility — New IDEs, new infra providers, and new image registries can be added by implementing the existing interfaces in app/gitspace/orchestrator/ide/, app/services/infraprovider/, and the registry layer, without modifying the orchestrator core.

References

• app/gitspace/orchestrator/container/container_orchestrator.go
• app/gitspace/orchestrator/ide/factory.go
• app/gitspace/orchestrator/runarg/resolver.go
• app/services/gitspace/gitspace.go
• app/services/infraprovider/infraprovider.go
• app/api/controller/gitspace/controller.go

Doramagic Pitfall Log

Found 11 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: identity.distribution | https://github.com/harness/harness

2. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/harness/harness

3. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/harness/harness

4. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/harness/harness

5. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/harness/harness

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/harness/harness/issues/3701

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/harness/harness/issues/3697

8. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/harness/harness/issues/3699

9. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/harness/harness/issues/3696

10. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/harness/harness

11. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/harness/harness

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using harness with real data or production workflows.

• Feature Request: Add context compaction and clearing controls - github / github_issue
• Feature Request: Display context window size and current usage - github / github_issue
• IsAncesterOf returns true for a trailing path segment that is not an anc - github / github_issue
• InfraProvider configuration read without authorization in Gitness - github / github_issue
• [[Security] Devcontainer feature tar extraction can write outside the fea](https://github.com/harness/harness/issues/3696) - github / github_issue
• v2.28.2 - github / github_release
• v2.28.1 - github / github_release
• v2.28.0 - github / github_release
• v2.27.2 - github / github_release
• v2.27.1 - github / github_release
• v2.27.0 - github / github_release
• v3.3.0 | Harness Open Source - github / github_release