Feature Requests

The DBSchemaApply step's globalSettings field is typed as object only. A runtime expression or string, such as <+stage.variables.globalSettings>, fails pipeline save validation. Sibling fields on the same step (envVariables, delegateSelectors, settings) accept oneOf: [object, string]. Error on save Stage: db schema deploy — globalSettings: string found, object expected Expected: globalSettings accepts an expression or string and resolves it to a map at runtime, as the sibling fields do. Actual: save validation fails with the error above. Why we need it Our global_settings comes from a free-form ADF map (Liquibase globals such as log-level and label-filter). It differs per schema and is selected at runtime from the pipeline config matrix. We can't hard-code the keys in the template without losing the ability to pass arbitrary globals. Request Change globalSettings to oneOf: [object, string] (matching envVariables and settings) in the step-info schemas above, on both the server-side validation and the published schema.

Teams that run Amazon Redshift as a data warehouse cannot manage its schema changes through Database DevOps today, because Redshift is not a supported database platform. Pointing a generic PostgreSQL JDBC connector at Redshift is not a viable path at this such such that it would be great if we could add native Redshift support, including a connector with a connection test and support for the Database DevOps steps (apply schema, rollback, and so on) against Redshift. This lets organizations put warehouse schema changes through the same governed, auditable pipelines they already use for their other databases.

When running a LiquibaseCommand step with the status command, the verbose output (including how many changesets are pending against the target database) only appears in the step's console log. There's no way to capture that information as a pipeline output variable or a written file, so it can't be used in downstream steps for gating, notifications, or audit trails. We'd like the LiquibaseCommand step to expose its output the same way the DB Schema Apply step already exposes applied changesets as an output variable. This would let teams programmatically check pending changes before proceeding, without having to parse raw console logs.

Goal is to implement Checksum validation in CI for already executed changesets. DBSchema Test and Preview in CI using DBSchema/dbinstance is counted against resource constraint which in turn blocks CD using same DBSchema/dbinstance. Feature Request is to have lockfree/resource constraint free native method to perform checksum validation in CI

Able to edit comments in SQL files, but the current DBDevOps pipeline fails if comments are modified after a changeset has been applied. Comments can be added or edited in a changeset even after it has been executed. Editing comments should not trigger changeset re-execution or checksum validation, as comments are non-functional changes. Currently, every comment modification requires manually recalculating the checksum and rerunning the pipeline. This behavior was validated using a test changeset where the comment was edited after the changeset had already been executed.

In a trunk- based development model, Harness should support a separate promotion PR per environment, enab ling controlled, environment- specific promotion gates without diverging from the trunk. we discussed this as being a step that will allow adding context to a change and a step that can check it back into git.

github connectors can be different for each environment. CD pipeline need to switch connector for each env so that it can still connect with same DBSchema but github connector expression resolved to env specific connector name

Problem Statement: The current UI experience for DB Governance creates the impression of a broken product for new users and large teams like PayPal. Unexpected Redirection: When a user clicks the "DB Governance" tab, they are redirected out of the module and into Project Settings. This is non-intuitive; users (including PayPal's Database Enterprise team) assume the page failed to load or they have hit a regression. Silent RBAC Blocking: If a user lacks specific permissions, the "Build Policy" button is "silently blocked" by a client-side guard. There is no error message, tooltip, or "Request Access" workflow, leaving the user stuck without a path forward. Onboarding Discoverability: Important buttons are hidden behind secondary navigation (e.g., needing to click a "close" icon to reveal the policy builder) once the redirect occurs. Requested UI Enhancements: Dedicated Module Landing Page: Stop the redirect to Project Settings. Create a dedicated landing page within the DB DevOps module for Governance. If no policies exist, show an "Onboarding/Get Started" state. Explicit RBAC Feedback: If a UI element (like "Build Policy") is blocked by permissions, show a clear visual indicator (lock icon or greyed out) with a tooltip explaining exactly which permission is missing. Direct Navigation to Org/Account Policies: If the user is at the project scope but needs to see policies defined at the Org or Account level, provide a "View Parent Policies" link directly in the module rather than requiring manual scope switching.

When using the DBApply step, if there is an error users are required to set up a second run step to parse execution logs for error messages to update ticketing systems, having the errors as an accesible expression during rollback would be really useful.