List of FAQs we've answered in this article
What determines what shows up in the "Commits in this branch" panel?
Some users are asking what determines the commits displayed in the Commits in this branch section?
For example, why does the following screenshot say "No commits were detected in this branch"?
The commits displayed are the net new commits that exist in the current (feature) branch selected on your Dev Sandbox, but do not exist in the next downstream branch.
In this example, the feature/Account.updates branch is in sync with the INT branch (the next environment in the Pipeline), therefore there are no new commits to display.
But after committing more changes to the feature/Account.updates branch, which have not been pushed to INT branch, these commits will show in the Commits in this branch section.
How can I check that the webhooks for pipelines are configured?
Gearset's pipeline functionality relies on webhooks for your Git provider to communicate to Gearset and trigger jobs.
On the CI dashboard by clicking on Webhook setup... for a given CI job, you can check if the webhook of that CI job in the pipeline have been set up.
Additionally, you can verify the set-up in your git provider. Example from GitHub:
The individual webhooks that git sends to Gearset should also show up here in the Recent Deliveries section (in GitHub in "Webhooks" section click on "Edit" > Recent Deliveries).
If you are troubleshooting why a job hasn't triggered, checking if the webhook has been sent by the Git provider is the first place to start.
If the webhook has been sent, please give the Gearset support team the timestamp of that webhook for us to help you find out what happened after the webhook was received.
Note: Any new CI job set up after August 2023 will try to add into an existing webhook pool instead of necessarily creating a new 1-to-1 mapping, so make sure to find the relevant webhook for your job when troubleshooting.
Further information on this can be found in our documentation on CI job and pipeline webhooks.
Check Pipeline webhook errors
On your Deployment pipelines page under "View Webhook errors" option you can check both new and previous errors related to your Pipeline.
This will give you a list of all the webhook errors.
Note: If the error is that the webhook didn't fire, this will not show in these logs as it is an issue on the Git side rather than the Gearset side.
What is the purpose of the Developer Sandbox compared to static environments?
A Developer Sandbox is a type of environment designed to allow you (and your teammates) to get your changes into the Pipeline.
It's essentially another entry point (with the others being either our Compare and deploy flow, or alternatively creating a pull request directly in version control system, e.g. GitHub, Azure DevOps etc).
The typical workflow is either:
You work on your feature (maybe in VS Code) and push the changes to the feature branch, or
You make the changes directly in a Dev Sandbox org, and push these changes to a feature branch (which Gearset lets you do via the Developer Sandbox environment in the Pipeline).
If you're creating a new branch, select New feature option. If you're adding more changes to an existing feature branch, select Commit more changes... option.
Creating a pull request
Once you have your changes in a feature branch, you can then use the Developer Sandbox environment UI to select Create a pull request... - this opens a pull request targeting the next 'static' environment in your Gearset Pipeline (e.g. INT environment in above scenario).
Note: You can swap the feature branch on the Dev Sandbox at any time. This of these feature branches as your "short-lived" branches, since they'll be deleted once the feature has gone through the entire Pipeline up to Prod environment.
Static environments and "long-lived" branches
Static environments are for the "long-lived" branches. Long-lived branches are used for your CI jobs. These are branches which represent the current state of an environment, e.g. STG (Staging), INT (Integration), UAT (User Acceptance Testing), or Production.
Can Gearset propagate changes through a Pipeline using the original pull request author?
Yes, Gearset allows Pipeline users to keep the original PR author when propagating through a pipeline.
Currently this feature is only supported by thse VCS providers: GitHub, Azure DevOps, Bitbucket, and GitLab (as we have specified here).
Note: If you have a long-standing pipeline you will need to re-authenticate your Git Provider on Source control and services page for this to work.
Can I use "Squash" or "Rebase" merge methods with Pipelines?
Short answer is no, you can't.
Depending on your Version Control System (VCS), you may have the option to utilise different methods to merge your changes into target branches (source branches of your CI jobs).
Usually these are "merge commit", "squash" and "rebase" as explained in the following GitHub article about pull request merges.
Using "squash" will combine (squash) your pull request's commits into a single new commit hash before layering that onto your target branch.
And "rebase" will actually create new commits to layer onto the target and you wouldn't be able to tell a feature merged in at a particular point in time. This article from Atlassian goes into more detail on rebasing: Merging vs. rebasing.
Gearset Pipelines is compatible only with merge commits
Since Gearset Pipelines keeps an accurate comparison of the commit differences between your feature and "long-lived" environment branches, to allow back propagation and easy identification of drift as new features pass through, the only method compatible with Pipelines is to use merge commits.
This is the default setting for most Version Control Systems, but it may be worth checking if you believe it to be different for your repo before using Pipelines. This is particularly important because using other merge methods can cause unexpected behaviour with Pipelines synchronisation.
What about fast-forward merging?
"Fast-forward" is also sometimes an option present on Version Control Systems, which is explained in this Atlassian article.
"Fast-forward" essentially means the tip of the target branch (an environment branch, like main) is moved to the tip of the source branch upon merging. The fast-forward option is only available if the 2 branches haven't diverged at all (that is, no extra commits have layered onto the target since carving the feature branch out and adding new work).
Why fast-forward merging isn't supported in Pipelines
This also isn't supported in Pipelines due to the fact that it breaks isolation of the commits present in the original feature branch vs any other commits that may be present on the target branch, resulting in the back propagation of unexpected commits/files to other environments.
Can I see who owns the Pipelines?
Yes, on the Deployment pipelines page click on the Pipeline dropdown icon. This allows you to preview both user-owned and team-shared Pipelines.
User-owned Pipelines will show who the Pipeline owner is.
Team-shared Pipelines aren't owned by a single Gearset user. Instead, they're owned by all the team Owners on your Gearset team.
Why can't I select "Promote changes" button in the Pipeline?
In Gearset Pipelines, it is possible that either you or your colleague may not be able to click on "Promote changes" button in order to merge the PR into the environment.
This is often related to a license assigned to a Gearset user, an org access given to a user, or a CI job access permission that a user has for a given CI job used in Pipelines.
The notification you may see in Gearset when trying to "Promote changes" could be:
"You can't promote changes because you haven't been assigned Run permission to this job, or one or more connections have been deleted".
Click on the arrow sign below: 
to preview the resolutions depending on the Pipeline type you're working on.
Resolution for team-shared Pipelines
Resolution for team-shared Pipelines
Usually, this is because the user who tries to promote changes does not have the Run permission for the CI job (Pipeline environment) that the PR is open against.
How to fix it?
On the Pipelines & CI job page select the team-shared Pipeline that the CI job belongs to:
Then find the CI job in question (in this example it's UAT job), make sure the user who tried to promote changes is added to the job and has the Run permission assigned to them.
Below video shows how to add a new user to the CI job and assign the Run permission.
Resolution for user-owned Pipelines
Resolution for user-owned Pipelines
It's possible a team member (who is not the Pipeline owner) tries to push a PR to one of the environments and comes across this below notification, and the "Promote changes" button is greyed out.
"You can't promote changes for one of the following reasons: You may not have an Enterprise license, the org connection could have been removed, or you do not have delegated access to the org."
How to fix it?
The owner of the org connection must delegate a Deployment level access to the org - the access needs to be given to the user who wants to promote the PR.
This can be done on Delegate org access page in Gearset.
Check our documentation on how to assign permissions to org for team members.
In most cases, the Pipeline owner is usually the owner of the org connection used for the environment (CI job).
Note: Remember that "Comparison" or "Validation" level access don't allow other users to promote PRs to Pipeline environments!
Why is "New feature" button disabled for team different users?
Are you seeing the "New feature" button being disabled (greyed out) for some of your colleagues on the team who work on the same Pipeline?
This is usually due to the permission level that a Gearset user has for the Pipeline environment. When a team member hovers the over "New feature" button, they'd see below message:
"You can't create a new feature for one of the following reasons: the org connection could have been removed, or you do not have delegated access to the org."
Below we're explaining how to grant the affected user required access to allow them to create new features in the Pipeline.
Resolution for a user-owned Pipeline
Check if user is trying to create "New feature" from a Dev Sandbox that belongs to another member.
Why? The access to create a new feature should be allowed from the Dev org that has been assigned to the user, but may be blocked for all other Dev orgs.
How to allow user to create features from a given Dev org?The Pipeline owner (or the owner of the Dev org connection) will need to delegate an org access to the affected user, and give them a Deployment access (permission) to the org.
Note: "Comparison" or "Validation" permissions are not sufficient.
Check our documentation on how to assign permissions to org for team members.
Resolution for team-shared Pipelines
Any Team Owner on your Gearset team can navigate to Delegate org access page in our app, and delegate a Deployment level access to the Dev org from which affected user (Member) cannot create a "New feature".
Note: By default, any Member on your Gearset team should have access to select the "New feature" option in Pipelines - that is regardless of their permission level access to the team-shared Pipeline (e.g. "View" or "Edit" access), or the permission level access to the CI job (e.g. "Edit" or "Run" CI permissions) that user's Dev org is linked to.
Why is my Pipeline environment highlighted in red or yellow?
This usually happens when the most recent deployment to the org was failed (unsuccessful).
It will not block your Pipeline from performing future PR merges or CI deployments, so you have nothing to worry about.
What is the default behavior?
This notification is defaulted to clear off after a next successful org deployment.
Can I manually clear this notification?
Unfortunately, it isn't possible to manually clear off the yellow or red status from your Pipeline environment.
Do you see a yellow exclamation mark on your environment?
Do you see a yellow exclamation mark on your environment?
This usually indicates that your deployment was partially successful.
For example, you have combined both metadata and CPQ config data as part of the PR promotion, and CI job successfully deployed the metadata, but didn't manage to deploy all the CPQ.
Do you see a red cross on your environment?
Do you see a red cross on your environment?
This usually indicates that the most recent deployment was failed, and nothing got deployed to the target org.
A common scenario where CI job attempted to deploy only metadata items.
Why pull requests in "Recent promotion history" aren't organised based on the date/time they were merged?
We're expecting this to not be an issue observed in your Pipeline, unless you have decided to merge some of the PRs outside the Gearset Pipeline, and the actual merge happened directly in your VCS (e.g. GitHub, Azure DevOps, Bitbucket etc).
Were all of the PRs opened for that environment merged in Gearset?
If for any reason you've decided to merge your PRs directly in the VCS, instead of doing it in Gearset, a possible explanation may be:
Delays in webhook processing may lead to Gearset ending up merging your PRs not in the same order the PRs were promoted to a given Pipeline environment.
Therefore, the PRs would follow a different order on the "Recent promotion history" tab to the sequence you were expecting to see (e.g. PRs organised based on date or time they were merged etc).
Note: When you promote the PRs through Gearset, we lock the environment to which PR is being promoted and do not allow any other users to perform any other actions on that environment (e.g. PR merges) - not until your PR is deployed, or until it fails the validation.
Therefore, ensuring that PR promotion in your Pipeline happens only in Gearset app will eliminate the risk of users seeing any inconsistencies on the "Recent promotion history" tab.
Why does the "Recent promotion history" tab not show all the merged PRs?
It should be a rare scenario among our customers, but it may happen.
The PRs will be displayed on the "Recent promotion history" tab for a given Pipeline environment for as long as:
They were originally promoted in the Gearset app.
After a successful promotion/merge, the PR was not deleted from your Version Control System (e.g. GitHub, Azure DevOps, Bitbucket etc).
Why merged PRs shouldn't be deleted from my VCS systems?
Currently, Gearset relies on merged PRs being present in your VCS in order for our app to be able to display such PRs on the "Recent promotion history".
If you decide to delete the PR from your VCS, it'll stop showing in Gearset Pipelines on the history of all environments the PR was promoted to.
If you're working with Gearset Pipelines, ask yourself:
What is the use case for deleting promoted PRs from your VCS?
Is there a justified reason for that?
And finally, is the benefit of deleting PRs from the VCS higher than a downside of not being able to preview them on the history of promotions in Gearset app?
What else should I be aware of?
Any merges completed out of Gearset (i.e. merges done via your source control) will not appear in the promotion history of the Pipeline.
Pipelines (and underlying CI jobs) do not function with Forked Repositories where feature branches are raised from the fork to the main repo, as we need the source branch to be in the same repository to track commits.
What should I do if I get stuck with anything?
If you ever need support, just contact our live chat support by clicking the blue button in the bottom right in every Gearset screen.
A real human (no robots here) will get back to you very quickly! We typically reply in under 15 minutes.