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.
150 results found
-
add static code analysis results to pull request
Can you add the ability to add the static code analysis results to a pull request? Or link back to the deployment summary screen with the results displayed there?
4 votes -
OAuth support for outgoing webhooks
Currently outgoing webhooks support only basic authentication. It'd be useful to have oAuth support for outgoing webhooks for enhanced security.
5 votes -
Add the ability to restrict the Jira Projects Gearset can access
A Jira account may be linked to many projects which will never be interacted with through Gearset. However those projects might still be legitimate for the user, so they can change their project access on the Jira side. It would be great if we could select projects in the connection that we want to choose from when associating to a Jira item.
1 vote -
Ability to merge the pull request from inside gearset. It gives me option to stay in one tool and carry out all my opertions.
In Gearset we have option to raise the pull request but we cant approve merge them inside gearset. There should be a checkbox which if checked should go and merge that pull request. That will allow the user to stay in one screen/one tool i.e. gearset. If someone wants to keep its approval processes in bitbucket then checkbox will allow them to only raise pull request and not auto merge/approve.
4 votes -
Show associated JIRA ticket in Validated Packages & Deployment History and Export
We would like to view the associated JIRA in both the Validated Packages and Deployed History pages. In addition, we would like to export the associated JIRA tickets in the Export History Excel report, found in the Deployment History page.
We link our Jira stories to our Production deployments and we would need a way to report on which ticket is linked to which deployment. Currently this is only available if users are diligent enough to also write the story number in the Friendly Name or Notes.
This would be an extremely useful feature especially for companies undergoing SOX Compliance…
3 votes -
Remember last used repository and branch for Azure DevOps integration
Remember the last used repository and branch in all places.
2 votes -
Need a Integration of Gearset & Jira , once the user story is updated in Jira , My gearset job will get triggered
Need a Integration of Gearset & Jira , once the user story is updated in Jira , My gearset job will get triggered and deploy the components related to that user story.
and once the deployment is done , update the jira ticket status as deployment done.2 votes -
Select source control based on actual setup/connections when starting comparison
When starting a comparison and selecting source/target environments for Source Control - it shows all connection types including those that I haven't connected.
With browser cache, it seems to remember the one you selected last. However, for new users (or when you clear cache) it'd be ideal if Gearset would default your source control on this screen to whatever the user has connected. Once a user has connected a source, there's no sense in having the user choose it again at this step.
3 votes -
Jira ticket association should carry over to deployment merges and comparison refreshes
If I clone a deployment, it copies all the associated Jira tickets, but if I merge two deployments, the list of associated Jira tickets is empty. Is that how it is supposed to work? I would expect a union of the lists of all the merged deployments.
The same would apply to comparison refreshes.
1 vote -
Jira: Ability to pass a list of Jira ticket Ids vs. single entry
Would really benefit from being able to paste a list of Jira Ids, e.g. comma-delimited (similar to specified tests) on final deployment. Hate giving up validation / deployment status writebacks to Jira, but often we have packages spanning dozens of Jira tickets and entry can be time-consuming, especially if there is a failure or refresh needed and Jira ticket associations get lost from the draft.
1 vote -
Ability to trigger different CI jobs or changing the targets based on the user who did the commit in source control
Related to CI jobs can you set up multiple jobs to trigger based on which user did the commit to source control? The goal would be having the deployment / last modified dates in SF reflect which user did the commit in source control and triggered the CI job.
I don't think that's possible as I don't see any kind of filter or way to manage which CI job should fire when source control is updated so the audit history in SF will only reflect one specific user doing the deployments and people would need to review the details in…
1 vote -
Github: Ability to select Reviewers for pull requests created in Gearset
Currently, you can create a PR after a successful deployment in Gearset. You're able to provide a description and even select it as a draft.
However, the only potentially necessary field that's missing is "reviewers". This means any CI/CD setup you have that requires an approval requires the user to go into Github just to add the reviewer.
Since Gearset would have all the team members (and those with linked github accounts), it seems it might be an opportunity to select based on that list and pass the linked username on to github in the PR creation to keep end…
2 votes -
Enable Dependency Cleaner only jobs on Git repos
Similar to Unit Test jobs for connected Salesforce orgs, it would be great to have independent Dependency Cleaner jobs for our source repos to help identify problems separate from any particular commit.
In our flow, not every commit goes through Gearset, so it's possible that our repo could become "undeployable" as a result of these non-Gearset commits. If this occurs, it then comes confusing on the next Gearset commit since the Dependency Cleaner will add all the deletions it deems required which don't relate at all to the PR being reviewed.
A the end of the day, we'd like our…
3 votes -
Basic Authentication with Jira
As our local hosted Jira instance doesn't allow unnamed connections it would be great to have a basic (username + password) authentication for Jira as well as Bitbucket.
1 vote -
Allow outgoing webhook option to be configured for Compare and Deploy
I need the option to configure an outgoing webhook when deploying via 'Compare and Deploy' feature. Currently webhooks are only available with the CI jobs.
3 votes -
Show In-Progress Validation jobs when clicking 'Details' in GitHub PR
When viewing a GitHub PR and you have a status check that's in progress, clicking 'Details' should take you to the validation only job page and show all validations (including those in progress).
Currently this page only shows you completed validations which makes it confusing to use at first and you have to navigate to 'Continuous Integration' and find the validation job there.
2 votes -
Repository Rebasing
Allows the Git repository to be rebased from the latest and greatest metadata from a target organization. In just few clicks the gearset will download all the latest metadata from a target org and will check in it inside master branch
1 vote -
allow users to customize Slack notifications
It would be great to have some ability to customize the notifications, specifically:
- change sender/title. right now it just shows up as my name.
- add a link to the monitoring history to allow wasy one-click into monitoring reports to see what specifically has changed.1 vote -
Add Validate pull requests for custom git
We have self-Manged Gitlab as a git provider.
It would be good to have the possibility to allow to run validations on pull requests for custom git repositories orsupport on-prem GitLab (submitted as https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/39728857-add-validate-pull-requests-for-on-prem-gitlab)
7 votes -
Enable tracking / comparison of code not in the force-app/main/default folder
SFDX officially supports tracking of source within the same package in more than one folder. The "standard" folder may be used, but you are also able to create a folder hierarchy that's more akin to a "modularization"
It can for example look like this:
force-app (any names goes here)
-> main
--> default
----> aura / classes / pages
-> module1
--> aura/classes/pages
-> module2
--> aura/classes/pagesCurrently, only the metadata inside the force-app/main/default folder is seen. It would amazing if git integration could take other folders into account too. Both for Deployments from and to Git (for…
2 votes
- Don't see your idea?