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.

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.

Did this answer your question?