Account-level settings for pipelines

Configure settings pipelines at the account-level

As a Codefresh account administrator, you can define global settings for pipelines which are inherited by all new pipelines created in the account.
Users can still override specific settings for individual pipelines.

Account-level pipeline settings

Pipeline functionality	Account-level setting	Description
Project	Auto-create projects for teams	Enabled by default, automatically creates projects when adding teams to the account.
Create	Pipeline creation options	Define if users can new pipelines from templates or by cloning existing pipelines.
	Allowed sources for pipeline YAMLs	Enable/disable sources for pipeline YAMLs.
Scopes	Pipeline scopes	Control access to endpoints exposed by the pipeline.
	Kubernetes cluster-contexts for pipelines	Define if users can select the clusters to which the pipeline has access.
Build	Pausing build executions	Define if users can pause builds for new and existing pipelines in the account.
	Restarting from failed steps	Enable option to restart pipelines from failed steps instead of from the beginning.
	Memory usage warning for pipeline builds	Enable alerts when pipelines reach/exceed the threshold.
	Default behavior for build step	Configure push image options for build steps.
	Default behavior for pending-approval step	Determine if pending-approval steps require manual action.
Other	Advanced options for pipelines	Configure options for build approval and pipeline volumes.
Argo Workflows	Enable pipelines with Argo Workflows	Create pipelines based on Argo Workflows.

Configure account-level settings for pipelines

Configure default settings for all pipelines in the account.

Before you begin

• Review account-level pipeline settings

How to

1. In the Codefresh UI, on the toolbar, click the Settings icon.
2. From Configuration in the sidebar, select Pipeline Settings.

Auto-create projects for teams

Enabled by default, auto-create projects for teams, automatically creates projects whenever you create teams in your account.
It also creates access-control rules for the same team to projects and pipelines, simplifying setup and saving time.

What does auto-create project do?

When you create a team, the auto-create project option:

• Creates a project with the same name as the team, and a tag for the project, also with the team name

• Creates a Project rule for the team with Read access to this project, and other projects with the same project tag

• Creates a Pipeline rule for the team, with all privileges, excluding Debug

NOTE
Once created, there is no synchronization between the project and the team. Modifying or deleting the team has no impact on the project and its tags.

What are the benefits?
As you can see, this option both simplifies and strengthens access-control:

• Using the Project rule automatically created for the team to grants access to additional projects simply by assigning the same tag to the other projects.
• Avoids the need to create rules per pipeline for the same project. The Pipeline rule automatically created for the team, automatically grants the same permissions to all pipelines in the same project. New pipelines in the project automatically inherit these permissions.
• Easily grant the same permissions to other teams for the same pipelines by creating Pipeline rules for the teams with the same project tags.

Pipeline creation options

Define if users can create pipelines from pipeline templates or by cloning existing pipelines. See Creating pipelines.

• Pipeline templates
  Enabling this option allows users to select a pipeline tagged as a template as the source of the new pipeline. Templates are simply pipelines “marked” as templates. There is no technical difference between templates and actual pipelines.
  See create pipelines from a pipeline template.

• Cloning existing pipeline
  Enabling this option allows users to create a pipeline by cloning an existing pipeline. Cloning an existing pipelines also copies its triggers and other parameters.

Allowed sources for pipeline YAMLs

If required, restrict the sources from which users can create or upload YAML files for a pipeline workflow.

The options are:

• Inline YAML: Enable/disable the inline editor where YAML is stored in Codefresh SaaS
• YAML from repository: Enable/disable pipeline uploading YAMLs from connected Git repositories
• YAML from external URLs: Enable/disable loading YAMLs for pipelines from external URLs

NOTE
You must allow at least one of these options so that users can create new pipelines.
We suggest selecting the Inline YAML option when users are still learning about Codefresh and want to experiment.

Pipeline scopes

Define the account-level scopes for resources, inherited by all pipelines in the account, through full access, read/write access, or CRUD permissions.

Kubernetes cluster-contexts for pipelines

By default, all pipelines in the account can access all clusters integrated with Codefresh. Restrict pipeline access to clusters by enabling cluster-injection for individual pipelines in the account.

Selectively restricting access to clusters for a pipeline:

• Enhances security by restricting access to users from different teams.
• Reduces the overall duration of the build by shortening the initialization phase. Codefresh authenticates the credentials of every cluster that the pipeline accesses during the initialization phase. This action affects build duration for accounts with large numbers of clusters.

You can then select specific clusters for individual pipelines, through the Kubernetes cluster option in the Pipeline’s Policies section.

Pausing build executions

Pause builds for all pipelines in the account. Pausing pipeline builds at the account level is useful for example during maintenance.

• Pause build execution is disabled by default.
• When enabled:
  • New pipelines in the account are paused immediately.
  • Existing pipelines with running builds are paused only after the builds have completed execution.
• Paused pipelines are set to status Pending, and remain in this status until Pause build execution is manually disabled for the account.

Restarting from failed steps

Enable or disable restarting pipelines directly from the failed step for all pipelines in the account. The setting affects the restart options displayed in the Builds view and step view.

• When enabled, allows users to restart the pipeline directly from the specific step that failed.
• When disabled, allows users to restart the pipeline from the beginning.

Individual pipeline are set to use the account’s setting by default, but users can override this setting to enable/disable failed step restart for the specific pipeline. See Pipeline settings - Policies.

Memory usage warning for pipeline builds

Select the memory-usage threshold for pipeline builds at which to display alerts.
Memory-usage thresholds for pipeline builds are useful to both avoid premature and unnecessary warnings, and get timely warnings to avoid build failures, as needed.

Accounts with pipelines that do not consume a lot of memory can have higher thresholds, or even the maximum threshold, as they are unikely to hit available memory limits.
Resource-intensive pipelines on the contrary require lower thresholds for timely warnings to prevent build failures. 90% is recommended for such pipelines.

The selected threshold applies to all pipelines in the account. Users can always override it for individual pipelines. See Runtime settings.

Default behavior for build steps

According to your organization’s needs, configure if and how the build step pushes built images.

The options are:

• Explicitly define in the build step if to push the built image to the registry or not
• Automatically push all built images to the default registry
• Do NOT push built images anywhere by default

Default behavior for pending-approval step

Configure if manual confirmation is required after clicking the Approve or Reject buttons for pending-approval steps. When required, a confirmation prompt is displayed on clicking Approve or Reject.

• None: No manual intervention required on clicking either Approve or Reject.
• All: Require manual intervention for both Approve and Reject.
• Approve only: Require manual intervention only after Approve.
• Reject only: Require manual intervention only after Reject.

Advanced options for pipelines

Configure the default settings that define advanced behavior for pipelines.

• Manage shared volumes for builds pending approval
  Define if to retain or discard the volume when a pipeline build is pending approval.

  NOTE
  This option affects pipeline resources and/or billing in the case of SaaS pricing.
  It will also affect users of existing pipelines that depend on this behavior.
  Once you either enable or disable this option for an account, we recommend leaving it unchanged.

• Concurrency policy for builds pending approval
  Determines whether pipeline builds pending approval are included or excluded from the concurrency count.

• Service account credentials for Amazon ECR authentication
  Define the Service Account to optionally use for authentication in Amazon ECR integrations.

• Public Marketplace Registry
  Set the default registry from which to pull images for all Public Marketplace Steps.
  You can select any Docker Registry integration that has been set up in Codefresh.

  Example: Public Marketplace Step image is defined to use Docker Hub. If you select a quay.io integration as the Public Marketplace Registry, all Public Marketplace Step images are pulled from quay.io instead of from Docker Hub.

  NOTE
  The selected registry affects only custom or typed steps.
  
  The default registry selected for Public Marketplace steps is ignored in all built-in pipeline steps: git-clone, freestyle, build, push, composition, launch test environment, deploy, and approval. For detailed information on built-in steps, see Steps in pipelines.

Related articles

Creating Pipelines
Codefresh YAML for pipeline definitions
Git integration