Feature Requests

Summary Add a subscription feature to receive email notifications (preferably hourly digest ) for repository changes such as direct commits/pushes to default branch , new branches , and new tags , across all repos in a project , without requiring pipelines. Problem Many teams manage hundreds or thousands of repositories and need lightweight monitoring when code changes happen. PR-based notifications don’t cover cases where changes are pushed directly to branches or when tags/branches are created. Building pipelines for every repository just to get notifications is not desirable. Requested Capability A project-level (or org-level) setting to: * Subscribe to repo events: * Push/commit to default branch (e.g., main ) * Branch created * Tag created * Choose recipients: * Repo admins and/or configured email distro list / user groups * Choose notification style: * Hourly digest (preferred), optionally immediate/daily * Scope: * All repositories in a project (with optional include/exclude filters) Why it matters * Improves governance/visibility for large repo fleets * Supports compliance and operational awareness * Avoids requiring pipelines or custom tooling purely for notifications

The current harness.code.repo.standards OPA package provides limited visibility into repository configurations, restricting its ability to enforce comprehensive code repository governance standards. While basic validations (default branch existence, repository metadata) are supported, there is no access to branch protection rules, branch naming patterns, or detailed branch governance configurations within OPA policy evaluation. This limitation forces organizations to implement separate validation mechanisms (API-based scripts, external tools) to enforce branch governance standards, creating fragmented governance processes and reducing the effectiveness of Policy as Code initiatives.

We are looking for a Git commit graph feature that provides a consolidated, visual representation of all commits made across every branch and tag within our repository (similar to a feature available in BitBucket). Currently, viewing commit history requires switching between branches or relying on limited visualization tools, which makes tracking overall development progress, branching patterns, and merge history difficult. We request support for enabling or introducing a unified commit graph view that: • Displays commits from all branches and tags in a single, comprehensive graph • Helps visualize relationships, merges, and divergence points • Improves collaboration by giving the entire team a clear snapshot of ongoing and past work • Reduces time spent manually checking multiple branches for commit activity This feature would significantly enhance our workflow and version-tracking efficiency.

Add dark mode option to Gitness UI

We need a flexible branching model with naming conventions (like master, feature/, bugfix/, release/, hotfix/, custom etc) for managing the code that helps in streamlining development and deployment processes within the repository. As per the screenshot attached, we expect the same functionality like bitbucket in Harness code repository.

HTTP Headers for outgoing webhooks in Harness Code Repositories. Currently, when a webhook is triggered by a repository event (e.g., Push, PR Merge), the payload is sent with standard headers. We need the ability to inject custom key-value pairs (e.g., Authorization: Bearer <token> or X-Custom-Auth: <secret>) into the request header.

Enable read‑only collaborators to contribute code by forking a repository to their own project/org and opening a pull request back to the upstream repo—without requiring write access to the upstream. There are workarounds that offer a similar functionality, but we lose the PR UX and it makes policies and implementation more complex. Forks Allow a user to fork a repo into a chosen scope (account/org/project), preserving a fork linkage to the upstream (like GitHub). Provide Sync from upstream (UI and API) to update the fork’s default branch (equivalent to “Fetch upstream / Sync fork”). Cross‑Repository PRs (across forks): Allow creating a PR where base is an upstream repo/branch and compare is a branch in the user’s fork (“compare across forks” UX). Support the common flags: “Allow edits from maintainers,” status checks, merge strategies, and branch protections enforced by the destination repo’s rules. Governance & RBAC: Org/account setting to allow/disallow forks (private repos), mirroring GitHub’s forking policy toggles for private scopes. Clear visibility of the fork network, limits on fork depth, and audit events for fork/sync/PR actions

Requesting this feature for Harness Repositories. Other repository software vendors like Github already offer this feature, and when migrating to Harness Repos, developers express some challenge when they want to share or reference specific code in large files. Highlighting the selected line(s) is a bonus as well. Some other terms to aid in feature request searching: deeplinking, deep link, line code link, line anchor link

Hi, Just wanted to check if we can add a feature in harness to send notifications to the code owners and the PR creator if the PR is not merged for a week. This should trigger automatically and send email for all the repos which we have in harness. Regards Lokesh

I believe it’s a good idea to integrate Dependabot with the Harness codebase. You can use open-source projects such as Mend Renovate and build capabilities like internal organization dependency checks from your own artifact modules, JFrog, etc. This integration will enable DevEx teams to publish new inter-organization packages while ensuring that teams keep their dependencies up to date. It will also help development teams track their dependency versioning effectively.