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 branch that do not exist in the next downstream branch. In this example, the feature-alpha branch is in sync with the int branch (the next environment), therefore there are no new commits to display.

Gearset's pipeline functionality relies on webhooks for your git provider to communicate to Gearset and trigger jobs. You can check if the webhook of the CI jobs in the pipeline have been set up.

Additionally, you can verify the set-up in your git provider:

The individual webhooks that git sends to Gearset should also show up here in the Recent Deliveries section. 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 here

To check for any errors in these webhooks, you can use the webhook error log.

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.

A developer sandbox is a type of environment designed to allow you (and teammates) to get your changes into the Pipeline. It's essentially another entry point (with the others being our Compare & deploy flow or creating a pull request directly on version control system e.g. (GitHub).
​
The typical workflow is either:

Once you have your changes in a feature branch, you can then use the developer sandbox environment UI to create a pull request to your target 'static' environment.
​
​Note: you can swap the feature branch at any time, so you can think of these as your 'short-lived' branches since they'll be deleted once the feature has gone through the rest of the pipeline.
​
Static environments are for the long-running branches and built on top of a CI job. These are branches which represent the current state of an environment e.g. Staging, Integration and Production.

Yes, Gearset now allows pipeline users to keep the original PR author when propagating through a pipeline.

Notes:

Depending on your version control system you may have the option to utilise different methods to merge your changes into target branches. Usually these are 'merge commit', 'squash' and 'rebase' as explained in the following GitHub article. Using 'squash' will combine X commits down into 1 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.

Since Gearset Pipelines keeps an accurate comparison of the commit differences between your feature and long-standing 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 behaviour for most version control systems but may be worth checking if you believe it to be different for your repo before using Pipelines.