In order to set up Gearset Pipelines, you'll need the following access:

Read/write access to the repository you are intending to use as the basis of the Pipeline.
The ability to create webhooks on that repository.
Admin permissions on the Salesforce orgs you are intending to use in the Pipeline.
- You will typically require a Developer Edition, Enterprise Edition, Performance Edition, or Unlimited Edition Org to ensure full access to deployment and automation features.
- Salesforce Starter Edition Orgs have limited customization capabilities and do not support full metadata API access, which are essential for automated deployments so cannot be used.
An Automation Platform License assigned to your team in Gearset.

Additionally, if you'd like to integrate Jira with your Pipeline, you'll need to set this up for your team – which will require the involvement of at least one Jira admin.

Checking whether you have the correct permissions will look different depending on what source control provider you are using.

GitHub

Sign in to GitHub.
Navigate to the repository containing your Salesforce metadata.
Open 'Settings'.
Open 'Webhooks'.
Confirm you can see on this page the option to 'add webhook'.

GitHub Enterprise

First, confirm that you have completed these steps to connect to GitHub Enterprise. Then, follow the steps above to confirm that you can create webhooks for the repository you're intending to use for your Pipeline.

Bitbucket

Sign in to Bitbucket.
Navigate to the repository containing your Salesforce metadata.
Open 'Repository Settings'.
Open 'Webhooks'.
Confirm you can see on this page the option to 'add webhook'.

Bitbucket Server

First, confirm that you have completed these steps to connect to Bitbucket Server. Then, follow the steps above to confirm that you can create webhooks for the repository you're intending to use for your Pipeline.

GitLab

Sign in to GitLab.
Navigate to the repository containing your Salesforce metadata.
Open 'Settings'.
Open 'Webhooks'.
Confirm you can see on this page the option to 'add webhook'.

GitLab self-managed

First, confirm that you have completed these steps to connect to GitLab self-managed. Then, follow the steps above to confirm that you can create webhooks for the repository you're intending to use for your Pipeline.

Azure DevOps

Sign in to Azure DevOps.
Navigate to the repository containing your Salesforce metadata.
Open 'Project Settings'.
Open 'Service Hooks'.
Confirm you can see on this page the green icon to add a new service hook.

If you have any questions about setting up your Gearset Pipeline, please reach out to our team using the in-app chat.

Azure DevOps Server

First, confirm that you have completed these steps to connect to Azure DevOps Server. Then, follow the steps above to confirm that you can create webhooks for the repository you're intending to use for your Pipeline.

Minimum requirements for Pipeline's non-owners

The above describes what would be needed to create a Pipeline. Anyone in your Gearset team will be able to see the Pipeline but won't be able to interact with it (promote changes) if some permissions/settings have not been set.

Note that each node in the Pipeline is a CI job that has a branch as the source and an Org as the target, and that Gearset doesn't override any rule/access you have set to the repo, branches and Orgs used in the Pipeline. In order to use Gearset Pipelines as a team member, make sure to have the following:

License: An Automation Platform License assigned to your team in Gearset.
Repo/branches access: Read/write access to the repository used on your Pipeline. If your repo has some branch protection rules, team members will only be able to promote changes in the Pipeline connecting to branches that they have permission in your VCS.

If the CI job/Pipeline is user owned

Org access: Delegated org access (deployment level) to the Orgs in your Pipeline. Even if you have connected those orgs in your Gearset account with your credentials, you won't be able to deploy into it using a Pipeline created by someone else - you'd need to deploy through the connection of the Pipeline owner. Example: If you'll be deploying to Integration and UAT but not to Production, the Pipeline owner needs to delegate Deployment level Org access to their connection to Integration and UAT orgs, but not to Production. Learn more about delegating org access in this other article.

If the CI job/Pipeline is team-shared

Team owners will need to give the run or edit permission for the CI job. Via the User permissions page. More information on setting the user permissions can be found here.

By assigning Run access to a CI job for a team member, you're essentially giving that member a permission to run the job and deploy - that is regardless of org access permissions settings in Delegate org access section.

Editing a pipeline

For users who want to edit a pipeline (such as moving environments or creating a new environment) but who are not the Pipeline owner. Make sure to have the following:

The Only editable by pipeline owner toggle needs to turned off. (This can be found under the Edit pipeline details... in the settings of the pipeline)