Global settings for pipelines

Configure settings for pipeline templates, YAML sources and build behavior for all pipelines in account

As a Codefresh account administrator, you can define global settings for all the pipelines in the account. Users can still override some settings for individual pipelines.

Account-level pipeline setting	Description
Pause pipeline executions	Define if users can pause builds for new and existing pipelines in the account.
New pipeline creation options	Define if users can new pipelines from templates or by cloning existing pipelines.
Configure pipeline scopes	Control access to endpoints exposed by the pipeline.
Auto-create projects for teams	Enabled by default, automatically creates projects when adding teams to the account.
Enabling cluster-contexts for pipelines	Define if users can select the clusters to which the pipeline has access.
Enabling cluster-contexts for pipelines	Enable/disable sources for pipeline YAMLs.
Memory usage warning for pipeline builds	Enable alerts when pipelines reach/exceed the threshold.
Advanced pipeline options	Configure options for build approval and pipeline volumes.
Default behavior for build step	Configure push image options for build steps.

Access global pipeline settings

Global settings for pipelines are set for the account and inherited by all pipelines in the account.

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

Pause pipeline executions

Pause builds for pipelines at the account level, 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.

New pipeline creation options

Here you can define if users can create pipelines from existing pipelines or from scratch:

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

• Clone 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 associated parameters.

Configure 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.

TIP: As a Codefresh administrator, you can override the account-level scopes for a specific pipeline by configuring custom scopes. The custom scopes are inherited by all the builds for that pipeline.

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 pipeline, 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

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:

• Use the Project rule automatically created for the team to grant 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.

Enabling 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.

1. In the Codefresh UI, on the toolbar, click the Settings icon.
2. From Configuration in the sidebar, select Pipeline Settings.
3. Toggle Kubernetes cluster context pipeline injection to ON.

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

Configure sources for pipeline YAMLs

Here you can restrict the sources of pipeline YAML that users can select. The options are:

• Enable/Disable the inline editor where YAML is stored in Codefresh SaaS
• Enable/disable pipeline YAML from connected Git repositories
• Enable/disable pipeline YAML from external URLs

You need to allow at least one of these options so that users can create new pipelines. We suggest leaving the first option enabled when users are still learning about Codefresh and want to experiment.

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.

Since Codefresh displays the banner alert when the build memory exceeds the selected threshold, setting the threshold at 100%, means that the pipeline has already failed when you see the alert banner.

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

Advanced pipeline options

Here you can set the defaults for advanced pipeline behavior. The options are:

• Keep or discard the volume when a pipeline is entering approval state
• Whether pipelines in approval state count or not against concurrency
• Define the Service Account for Amazon ECR integration.
• Set the default registry from which to pull images for all public Public Marketplace Steps. You can select any Docker Registry integration setup in Codefresh.
  • Example: Public Marketplace Step image is defined to use Docker Hub. If you select a quay.io integration, all Public Marketplace Step images are pulled from quay.io instead of Docker Hub.

    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. The selected registry affects only custom or typed steps.

Note that the first 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. It is best to enable/disable this option only once at the beginning.

Default behavior for build step

Here you can decide if the build step will push images or not according to your organization’s needs. The options are:

1. Users need to decide if an image will be pushed or not after it is built
2. All built images are automatically pushed to the default registry
3. All built images are NOT pushed anywhere by default

Note that this behavior is simply a convenience feature for legacy pipelines. Users can still use a push step in a pipeline and always push an image to a registry regardless of what was chosen in the build step.

Related articles

Creating Pipelines
Codefresh YAML for pipeline definitions
Git Integration