Advanced settings
The Settings tab also will reveal a couple of advanced features that will let you fine-tune your pipeline.
CPU
The CPU option allows you to select the processor architecture for the pipeline, depending on your application’s requirements.
Available options:
- x86 - The default architecture is Intel/AMD, compatible with most applications
- ARM64 - The ARM architecture, used for example in mobile devices and ARM containers
Image loading...
Resources
This option lets you optimize the efficiency of your processes by assigning the resources on the basis of the tasks the pipeline performs:
- Nano: 2GB / 2vCPU
- Small: 3GB / 2vCPU
- Medium: 4GB / 2vCPU
- Large: 6GB / 2vCPU default
- XLarge: 8GB / 4vCPU
- X2Large: 16GB / 4vCPU
Priority
Priority determines how soon a queued pipeline will be triggered. For instance, if there are 4 pipelines in the queue, and you assign High priority to the last one, it will move up the line and be executed once the ongoing execution is completed:
Image loading...
Docker Build Cache scope
The Docker Build Cache optimizes Docker image build times by storing layers between pipeline runs.
Pipeline
The cache is limited to a single pipeline, providing the fastest performance because all operations are local. Use this scope to optimize isolated builds that do not need to share layers with other builds.
Project/Workspace
The cache is shared across all pipelines within the same project or workspace. This option may be slower when building layers, since they must be uploaded to an external cache. Use this scope if multiple pipelines in the same project can benefit from sharing common layers.
Image loading...
Force deploy from scratch
Most of the deployment actions are based on changesets, which means only the files from the latest revision are deployed. Checking 'Force deploy from scratch' will force Buddy to deploy all files from the repository on every execution. If the option is selected, the changeset trigger conditions added in the pipeline won't be taken into account.
Clear cache before execution
The cache stores a clone of the repository and dependencies required by your build, which massively reduces build times. In some cases, however, you may need to fetch the dependencies on every build execution. To do that, select the option 'Erase filesystem, Docker layers & cached container paths on run'. It will force Buddy to download the packages every time the pipeline is run. If the option is selected, the changeset trigger conditions added in the pipeline won't be taken into account.
Skip queued runs for same Git reference
If a user triggers a pipeline that's already in progress, the execution will be queued and won't start until the first one is over. If there are more executions queued (for example 5) and you check 'New run for same Git reference terminates runs in progress', Buddy will only run the newest execution (5th) and skip the rest (2-4).
Image loading...
Terminate runs in progress for same Git reference
If a user triggers a pipeline that's already in progress, the ongoing execution will be terminated and replaced with the new one.
Execute pipeline runs concurrently
Selecting the option lets you trigger multiple executions of a single pipeline simultaneously. This feature is useful if you want to test every single commit or test multiple branches at the same time.
Default description
The default description option lets you define a message that is automatically applied to every pipeline run. You can override this with a custom message when running pipeline manually.
Image loading...
Git Changeset Base
The Git Changeset Base option lets you define a branch or commit that serves as the reference point for calculating changes in the pipeline.
Available settings:
- Last commit
- Commit matching ref
- PR base branch
Image loading...
Filesystem Change Detection
Filesystem Change Detection allows you to monitor file changes and automatically trigger pipelines when specified changes are detected in the repository.
Available settings:
- Date modified
- File contents
Image loading...
Fetch all refs
When the pipeline is run, Buddy fetches only one Git reference to the pipeline filesystem (branch, tag or pull request). Selecting the 'Fetch all refs' option will force Buddy to fetch all Git references.
Image loading...
Shallow Clone depth
The clone depth specifies how many commits should be cloned to the filesystem on the pipeline execution. Creating a shallow clone is useful if your .git/
directory occupies too much space.
Image loading...
Quick Link
The Quick Link puts a label on your pipeline that lets you promptly access the associated website, e.g. to review changes after a deployment.
Image loading...
Pause pipeline on repeated failures
This option automatically pauses a pipeline after a defined number of consecutive failed runs. By default, pipelines are paused after 100 consecutive failures.
Image loading...
Status
The Status option controls a pipeline’s visibility and activity, both on the project dashboard and across the entire workspace.
Available options:
- Ignore pipeline status on project's dashboard - hides the pipeline status on the project's dashboard
- Turn off this pipeline - disables the pipeline, preventing it from being run
Image loading...
Trigger condition
Usually, your application is first built and then deployed to the server. However, not every change in the repository requires a build. In such cases, The Run if tab is the place to go to define certain conditions that will trigger the build.
Image loading...
Definition location
The Definition Location option allows you to store the pipeline configuration directly in a Git repository. This enables version control for pipeline definitions, improving transparency and management of deployments.
Image loading...
If a pipeline has already been created, its definition location can be modified in the settings. Simply select the Definition location
option from the context menu and adjust the configuration.
Image loading...
In the edit panel, you can enable the option to store the pipeline definition in a Git repository. Once saved, the pipeline will use the versioned configuration stored in the repository, making management and auditing easier.
Image loading...
When enabling the Definition Location, you need to specify:
- Project – the repository where the pipeline configuration is stored.
- Branch – the branch containing the configuration file.
- YAML Path – the exact location of the
.yml
file defining the pipeline.
Additional modules managed using YAML definition:
- Variables - Environment variables available to the pipeline
- Permissions - Pipeline access permissions
Image loading...
If the YAML filename contains .fixed
(e.g., Frontend.fixed.yml
), Buddy will apply the configuration from the initial branch across all branches listed in the codescope. The "initial branch" refers to the branch where the definition was first introduced.
Storing configuration in a Git repository
When stored in a repo, you choose between:
- Fixed branch: Pipeline always uses the YAML from a specific branch (like main), regardless of where code is pushed.
- Dynamic branch: Buddy picks up the YAML from the same branch or PR/tag being pushed, based on its
ref
.
Definition Variables in YAML
Created variables are also saved in the pipeline configuration YAML:
yamlvariables: - key: my_var value: '!encrypted f+ZkJjNjprzRy5sXz2SUxA==.cxBjMsZkmVHiqR4A3zpXJg==' type: VAR encrypted: true settable: ENABLED
Definition Permissions in YAML
Permissions set in the pipeline are also saved in the YAML pipeline configuration:
yamlpermissions: others: DEFAULT users: john.doe@example.com: READ_WRITE jane.smith@example.com: READ_WRITE
Visibility & permissions
The Permissions tab in the pipeline settings allows you to restrict pipeline's visibility and scope of operations to individual users and groups.
Image loading...
The permissions can be restricted to the following built-in roles:
- None (Deny) – the user cannot see the pipeline in the project at all
- Project role – the permission defined in the role with which the user was assigned to the project (default)
- View-only – the user can browse the pipeline but cannot run or modify its settings
- Run-only – the user can run the pipeline, but cannot modify its settings
- Manage – the user can run and modify the pipeline, just like with the Developer role
Last modified on Oct 3, 2025