GitOps settings

Admins, or users with the Configure settings permission, can adjust system-wide settings for GitOps under Settings > GitOps. On this page, adjust settings that apply to entities, to Scorecards, and to Workflows.

To learn more about using a GitOps workflow for Cortex, see Using GitOps for Cortex.

GitOps entities settings

In the Entities tab of the GitOps Settings page, you can adjust settings that affect entities.

Processing

These settings allow you to control how Cortex processes and validates your GitOps-managed configuration, helping you ensure that only the desired files and changes are ingested and that errors are surfaced appropriately.

• Cortex YAML processing: This setting enables or disables the processing of cortex.yaml files. If disabled, Cortex will not process these files for entity updates, but package and OpenAPI breaking change detections will still process.

• Process Cortex properties: This setting controls whether Cortex processes the cortex-properties.yaml file after GitOps processing. If disabled, Cortex will ignore cortex-properties.yaml files.

• Package parsing during GitOps processing: This setting determines if Cortex will parse package information (such as dependencies) during GitOps processing. If disabled, package parsing is skipped.

• OpenAPI detection: This setting determines whether Cortex checks for breaking changes in API specs defined in cortex.yaml files. If disabled, Cortex does not check for these.

Linter checks

These options help you control the strictness and visibility of validation checks during your GitOps workflows, making it easier to catch and address configuration issues earlier.

• Linter check on non-parsable files: When disabled, GitOps processing will skip non-parsable entity YAML files in the repository. If you have errors in the processed YAMLs, the linter will fail regardless of this setting.

  • For example, if a YAML file is missing its x-cortex-type to define the entity type, that file would be considered non-parsable.

• GitOps linter check repository allowlist: Choose which repositories to run the linter check on. If none are selected, the check will run on all repositories.

• Pull requests linter result for warning violations: This option lets you choose whether the linter result for warning violations should result in success, neutral, or failure. This helps teams decide how strictly to enforce warnings in their CI/CD workflows. By default, if there are any errors in your YAML file, the linter will result with a failure.

Options by entity type

These settings allow you to control whether each type of entity can be created or edited via the UI or whether they must be managed exclusively through GitOps.

• Enable UI editing for new entity types: When enabled, entity editing can be done through the Cortex UI. When disabled, entities can only be edited through GitOps.

• Enable UI importing for new entity types: When enabled, entities can be imported through the Cortex UI. When disabled, entities can only be created through GitOps.

• Entity GitOps repository allowlist for new entity types: Choose which repositories to search for new entity types. If none are selected, Cortex will search all repositories.

Below these toggle settings, you can choose to enable UI editing and UI importing per entity type, and you can select which repositories to search for each entity type.

GitOps Scorecard settings

The GitOps Scorecard settings control how Scorecards are managed and edited in your workspace, allowing you to enforce a single source of truth and auditability for Scorecard changes.

Learn more about GitOps for Scorecards in Scorecards as code.

• Enable GitOps for Scorecard editing: When enabled, you can only edit Scorecards via GitOps, reagrdless of whether the Scorecard was originally created in the UI.

• Scorecard GitOps repository allowlist: Choose which repositories to search for new Scorecard YAML files. If none are selected, Cortex will search all repositories.

GitOps Workflow settings

The GitOps Workflow settings control how Workflows are managed and edited in your workspace, allowing you to enforce a single source of truth and auditability for Workflow changes.

Learn more about GitOps for Workflows in Workflows as code.

• Enable GitOps for Workflows editing: When enabled, you can only edit Workflows via GitOps. You can still create and delete Workflows in the Cortex UI.

• Workflow GitOps repository allowlist: Choose which repositories to search for new Workflow YAML files. If none are selected, Cortex will search all repositories.