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.
1439 results found
-
Provide a visual indicator on upstream systems when out of sync with master
Often times we see drift items added to PR's in our upstream systems. It would be nice to have an indicator that shows if a static branch is out of sync with master.
3 votes -
Pick up test classes to run from the apex class
Add a variable in apex classes where we can specify which test classes to run.
Recently you added the ability to specify the test classes to run on a pull request, which is great!
I know <ApexClassName>Test are automatically picked up by GS, but would be great if we could specify with
@TestClasses('CaseTestSuite,LeadTestSuite') or similar in the actual Apex Class and Gearset would automatically pick it up and add those test classes to the pull requests .3 votes -
sandbox seeding size
When deploying data to sandboxes, it would be helpful to get an approximation of the amount of data and file space a seeding job will need. I have on numerous occasions hit storage limits as a developer sandbox only has 200 megabytes of usable space.
3 votes -
Allow IN Operator for Data Deployments
When filtering for specific records with ID's, would be handy to have an IN operator for record selection.
3 votes -
It would be great to have a centralized way to view all components and static code analysis results for every commit within a branch.
It would be great to have a centralized view for all components and static code analysis results across every commit within a feature branch. For example, if a developer makes five commits to the same branch, it would be much more efficient to review the components and static code analysis results for the entire branch in one place, rather than checking each commit individually through the deployment history. Additionally, there should be an export option to easily share the results with developers. Thanks
3 votes -
Clickable Jira Request within Pipeline Promotion History
I would like the ability within the pipeline promotion history to make the Jira tickets clickable. That way a user could simply click the ticket reference to navigate directly to the request.
3 votes -
Add Salesforce Data Cloud sandboxes as an option for deployments
Salesforce Data Cloud sandboxes are now generally available but to promote changes from sandbox to production, the only options are through Data Kit and change sets, CLI, or DevOps Center. Having the option to use GearSet would be helpful so all deployments were managed the same.
3 votes -
Allow Adjusted Column Sizes to Persist in the Comparison Table
Have adjusted column sizes persist once they've been adjusted in the comparison table instead of resetting with each selection. Deploying changes to permission sets could be dramatically streamlined if it's possible to maintain resized columns. If column sizes were set to accommodate the name instead of giving them all the same size, that would also be a huge improvement. The other columns don't include as much info as the name column so it's a waste to give them so much space. It is also inconvenient to caret down in permission sets especially when looking for multiple fields in one permission…
3 votes -
Assigning a dev sandbox to a member should give them deployment access
Assigning a dev sandbox to a member should give them deployment access automatically, or at the very least I should be able to give deployment access in the same interface.
3 votes -
enable using a Repository Access Token instead of a Service Account
I would like to be able to use a repository access token instead of a service account to connect to VC (Bitbucket in my case). https://support.atlassian.com/bitbucket-cloud/docs/repository-access-tokens/
The main benefit for me would be the ability to conveniently authenticate while maintaining a high level of security, even in situations where corporate change management policies and SSO requirements can be cumbersome.
3 votes -
Allow configurable default settings for Jira integration
Allow us to customize the default behavior for the Gearset<>Jira integration. Currently, Gearset posts a comment on the linked Jira ticket every time a commit is started and completed. This creates a lot of noise on the ticket.
Currently the only way to customize the messages posted to Jira are on a ticket-by-ticket basis. Allowing an option to customize this at the org/pipeline level (e.g. only post a comment when a deployment succeeds) would be very helpful.
3 votes -
Compare Types on Comparison
For the pipelines observed when creating a feature branch and during comparison runs, a default filter is applied to the compared types without any metadata types selected (0). We would like to have a custom filter with metadata types for a specific pipeline pre-selected by default when the feature branch initiates the comparison.
3 votes -
Save sort order in Saved comparison pairs
It would be nice that the chosen sort order of the saved comparison pairs could be saved.
If I choose to sort the saved comparison pairs on Friendly name and i open a new tab of gearset, the saved comparison pairs in the new tab are sorted on last used. It would be nice that in the new tab, the saved comparison pairs are sorted based on the same column as the previous tab.3 votes -
Split Lightning Page Metadata Type
Think the Lightning Page metadata type needs to be split into 2 categories. Reason being it is the one metadata type that causes comparisons to run for extremely long times or even crash/time out. This happens because it trying to compare all of the lightning email templates users make. It would be better if lightning email templates were their own metadata type and the lightning page type was actually just lightning pages created for objects.
3 votes -
In a data deploy, allow filtering data by previously deployed parent objects.
For example, instead of "Only deploy Opportunity records that are children of the Account.Opportunities records that are being deployed" which filters opportunities by the accounts in the same deploy. You would have two deploys. The first would deploy accounts. The second would filter opportunities by those accounts already in the target org.
This would allow you to modularize deploys. You might want to mix and match subsets of data for specific projects. It would allow working around some of the shortcomings of the account hierarchy gearset magic. If there were transient errors (like exclusive locks) you could repeat a smaller…
3 votes -
Increase API call limits
There currently is a API limit of only 10 calls per hour for the reporting and audit API's. This makes it difficult when developing and testing applications that tie into the api. In our case we use the api to pipe the data into our observability platform for reporting and dashboarding. It would be nice to either increase to something not THAT low or to have a development override option of some sort that customers to request to temporary increase. I understand the need for some limits due to having a shared cloud platform but this seems to be on…
3 votes -
Grouping developer sandboxes in Pipelines - back-promotion to a group
Team,
Currently Gearset Pipelines only offers the option to connect a developer sandbox group to a single downstream environment. While back-promotion to a group isn't available yetCould you please enable it ?
3 votes -
Bulk resolving merge conflicts across multiple PRs (set resolution as Feature or Environment)
It would be great if there was the capability to bulk-apply Feature or Environment when resolving merge conflicts across multiple PRs. I have a few dozens that all need to be set to the same option, and it would be useful to handle this quickly rather than click on each one individually.
3 votes -
Give CI/CD Users the option to use a shared webhook or a new one in BitBucket
Gearset recently updated its automated webhook setup for new CI/CD jobs to use a shared webhook. For my team, we have configured each webhook for validation jobs to only run on PR creation/update and deployments to only run on branch pushes. By forcing the new jobs to a single shared job, it causes PR merges to trigger validations alongside the deployment (Which is time-consuming and needless).
Also, as my team has many legacy webhooks for our existing jobs, when we add a new job it seems Gearset randomly assigns it to an existing webhook. For our recent deployment-only job, it…
3 votes -
Attach specific Tests to Feature Branch Manually
I would like to have the ability to force a features jobs to run specific test(s) from the CI screen.
So if GS fails to detect a test class (either by error or b/c its not named in the expected convention) OR would have failed to catch breaking changes elsewhere, we can avoid/prevent this attaching a set of test classes to that feature branches deployment configuration in GS.
3 votes
- Don't see your idea?