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 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.
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. 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.
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 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:
you work on your feature (maybe in VS Code) and push the changes to the feature branch, or
you make the changes on a dev sandbox and push those to the feature branch (which we let you do via the developer sandbox environment).
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.
Can Gearset propagate changes through a pipeline using the original pull request author?
Yes, Gearset now allows pipeline users to keep the original PR author when propagating through a pipeline.
Notes:
Currently this feature is only supported by the VCS providers specified here.
If you have a long-standing pipeline you will need to re-authenticate your Git Provider for this to work.
Can I use 'Squash' or 'Rebase' merge methods with Pipelines?
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 setting for most version control systems but may be worth checking if you believe it to be different for your repo before using Pipelines, as using other merge methods can cause unexpected behaviour with Pipelines synchronisation.
Note - 'fast-forward' is also sometimes an option present on version control systems which is explained in this article, and 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).
This also isn't supported in Pipelines due to the fact 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, it is displayed on the Pipeline name's drop-down selection.
What else should I be aware of?
Any merges completed out of Gearset (i.e. Done via 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.