Skip to content

Help us improve Gearset

We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.

If you need any further support, please contact us at team@gearset.com.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

32 results found

  1. Allow automatic tagging of release commits

    I've found it very useful to be able to quickly identify release merge commits from our VCS. Being able to search for a tag in our VCS would allow us to easily compare one version to another without having to use something like git bisect. I'd like the option to automatically tag a commit (you could probably use the release name) would be helpful.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  2. add an option to sign commits with GPG key

    If a source control space has enforced GPG key signature for all commits, gearset is not able to push any commits.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  3. Populate Pull Request Templates from git providers

    When creating a pull request directly in Gearset, it would be ideal to pull in the existing templates defined in BitBucket or GitHub.

    A middle of the road solution (if GiHub or BitBucket's API doesn't support this) could be defining a pull request template in Gearset.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  4. Support org shape parameter for creating Scratch Orgs

    Currently definition files are required for creating scratch orgs but there is no support in GearSet for the use of the sourceOrg parameter as per the sfdx documentation here : https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_scratch_def.htm

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  5. Bitbucket pull request add Default Reviewers

    When using the "Create Pull Request" link on the deployment screen, please add the "Default Reviewers" to the BitBucket pull request.

    Currently we have to edit each pull request and add the reviewers manually.

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  6. CI Job notification email should report the actual errors directly instead of linking to CI Dashboard.

    This potentially can help the team to collaborate on the errors directly on Teams messages.

    For example, at present, the MS team notification says [A continuous integration validation job failed for validation job for PR # xx], but doesn't say which CI job name or what the validation/deployment error was.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  7. Ability for team members to manually run the CI

    Currently, only the owner of the CI job can manually run the CI. If the owner is out or unavailable, this creates a problem for team members because they have to deactivate the current job, clone and setup the new CI OR transfer ownership. Transferring ownership doesn't work if a team member is out unexpectedly, ill or doesn't have access to perform the transfer.

    It would be helpful if you could grant access to a group of team members who have access to manually run the CI. This would save a lot of time and prevent having to keep multiple…

    14 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    We have made changes to the app on the 29th of June release for Enterprise licensed Gearset users:

    Added the ability to run CI jobs belonging to other users if the source is a git repo and the target has deployment access delegated.

    We think this now covers the cases:
    - Allow an enterprise licensed user to run other people’s org to org CI jobs
    - Allow an enterprise licensed user to run other people’s git to org CI jobs

    We have not implemented allowing user to run other people’s org to git CI jobs. As this is sub use case is quite a specific interpretation of the original suggestion. Perfectly happy for it to be specified in another separate suggestion.

    We have updated the documentation to reflect this change – https://docs.gearset.com/en/articles/2533179-access-levels-in-gearset

    I hope this delivers the what your team needs. Feedback always welcome :)

  8. Include more details in webhook notifications

    It would be great if webhook would include, at least, the same information as email notifications. For example, Unit Testing job notifications via email contains the details about the unit tests that failed; however, webhook notification don't. We wanted to use webhooks to get notifications in MS Teams but without the same details, it's not that useful.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  9. Rerun Github validation on a PR without a new commit

    When a CI job is set to run on a PR creation, if the source destination is missing something that the deploy requires, it will fail. To solve this, we must go to the source destination, make settings changes, and then make an empty commit to the pull request to re-run the CI.

    It would be nice for there to be a link or button in Gearset to rerun the CI and update the Pull Request that the validation was successful.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    In the ‘continuous integration dashboard’ in Gearset, for ‘validate pull request’ jobs, there is a ‘run now’ play button to run the job manually. You can therefore update the target and then re-run the PR validation without needing an additional commit.

    To be able to run the ‘validate pull request’ job manually, you need to have permission to run the parent CI job manually (e.g. be the job owner).

  10. Ability to create Pull Requests for AWS CodeCommit

    Gearset can create Pull Requests for many of the source control systems that it integrates with, but not AWS CodeCommit.

    As AWS users, it would be very useful to use to have this ability so that we didn't need to switch systems to create Pull Requests.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  11. Require Jira Ticket Before Validation or Deployment

    We would like the ability to make the "Jira updates" section required (i.e. ticket selected) prior to validation or deployment.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    You can now require team members to link a Jira ticket before manual deployments and validations. 

    Simply, navigate to My Account -> Deployment Settings and enable the 'Require Jira Tickets' option. 

  12. Support integration with OKTA

    Salesforce orgs that have OKTA as a SSO Identify Provider cannot seem to be connected to Gearset using SF Authentication. Therefore is makes it impossible to do Monitoring and Tests.

    Please look into supporting OKTA SSO

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  13. Allow multiple Team owners to Connect to the bitbucket server through OAuth instead of creating a new link every time with in same Org

    With in an org if we have multiple owners working as multiple teams, Gearset should be able to allow other owners to connect to the same Biibucket server through OAuth, instead of creating a new link every time.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  14. Allow Updating of Associated Jira Ticket Statuses on Successful Deployment

    With Gearset's current the ability to associate a deployment with Jira tickets, and post updates as comments to the stages of deployments, the ability to choose the status (from what is defined in the status of the Jira Board), upon a SUCCESSFUL deployment, would be incredibly helpful in our environment plans for our projects.

    By being able to select the status to update all tickets to from the Jira board, we could effectively manage our custom stages for different projects.

    22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  15. Add link to test results in Microsoft Teams

    Please add a link to the test results as part of the notifications sent to Microsoft Teams. The integration with Slack already includes the link so it would be very helpful to have a similar integration in Microsoft Teams.

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  16. Improve Bitbucket Server integration for teams with large number of project/repositories

    ideally... gearset should not be hitting https://adlm.nielsen.com/bitbucket/rest/api/1.0/repos
    first. It should hit https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects to get a list of projects
    then allow the end user to select the project
    then https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects/{projectKey}/repos to get a list of repos on the project the end user selects

    12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  17. Ignore Unlocked Package Metadata In Comparisons

    Currently, metadata from Unlocked Packages show up when comparing against an org. This leads to duplication of metadata in source control repositories (correct DX package repository and incorrect monolithic, "happy-soup" repository).

    Using the Package2Member Object (Tooling API), it is possible to deduce whether or not a metadata item is part of an unlocked package. Therefore, it should be possible to ignore some or all unlocked packages (or any Package2 package), in a similar fashion to the way Gearset filters allow inclusion or exclusion of managed packages.

    17 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    In comparisons, all metadata from unlocked packages is included by default. However, some users wish to exclude unlocked package metadata from a comparison. This is so that they don't have to see metadata that they don't need to consider for their deployment.

    So we’ve added this ability! 

    Within the packaging sidebar on the right hand side of the large filter, there is now an option to Exclude unlocked packages from a comparison. Shown in brackets is the number of distinct unlocked packages identified across the two environments.

  18. Report CI validation/deployment status to source control

    When a CI job is triggered by a commit to source control, please update the source control system with the result of the build - so that e.g. with Bitbucket we could see the build result from pull requests as at https://confluence.atlassian.com/bitbucket/check-build-status-in-a-pull-request-945541505.html

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  19. Add support for incoming webhooks

    There's already a way to set up an outgoing webhook after a successful CI job run.

    It'd be nice to have a way for a CI job to have an incoming webhook from another service, such as ElectricFlow (a build platform).

    One use case would be for CI deployments to be dependent on external validation services.

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

  20. Gearset API to externally trigger Gearset actions

    It would be incredibly helpful to trigger Gearset comparisons, validations, deployments, etc. from an external source using an API. Our team uses GitHub for our VCS, which provides the perfect opportunity to:
    1. design webhooks to validate changes in order to approve a Pull Request
    2. design webhooks to automatically deploy changes to an org once the PR is approved.

    Additionally, CI tools such as Jenkins, TravisCI, TeamCity, etc could use such an API to design complex builds that still employ Gearset, but use the external tool for additional actions outside of what Gearset provides for their CI features.

    108 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    This is now available to everyone with an Enterprise license! Please see https://docs.gearset.com/en/articles/6099550-getting-started-with-the-gearset-api for more details. If anyone has feedback or suggestions, please contact us via the in-app widget.

← Previous 1
  • Don't see your idea?

Feedback and Knowledge Base