What determines what show 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 exists 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 setup.
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 send 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.
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.
Currently this feature is only supported in Github, Bitbucket and GitLab.
If you have a long standing pipeline you will need to re-authenticate your Git Provider for this to work.
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.