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.
86 results found
-
Preview Deployment Details in Deployment History
On the Deployment History page, it would be nice to have a little popup window to view some of the files from the Deployment Details instead of having to download the Deployment Report
7 votes -
Run Tests During CI Jobs
There are some similar but not exact posts below so I'm writing about a new one. We would like to be able to specify an option to run tests when deploying via a CI job from git (Bitbucket) in our release sandbox. If any of the specified tests fail, the CI job would fail and the deployment rolled back. It would be great is we could specify whether to roll it back or not when configuring the job but if that is too much too bite off, just failing the job would be helpful. Thanks!
3 votesIf you edit your CI job then you’ll have four options:
1. Default test behaviour
2. Don’t run any tests
3. Run only your tests
4. Run specific testsYou can select the test level that you’d like for your CI job and it will be respected and pass/fail your CI job accordingly.
Thanks for reporting and I hope this helps!
Kevin
-
Add Lead conversion support
Please add support for the LeadConvertSettings metadata.
See https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_leadconvertsettings.htm for details3 votes -
Support Wave Analytics Metadata
We have been engaging in quite a few Salesforce Analytics (ie. Wave Analytics, Einstein Analytics or whatever the current branding label) projects lately. Version control on all of the related metadata is critical it would be enormously beneficial for Gearset to be able to support these metadata elements.
The following Analytics metadata types are supported in the Metadata API:
WaveApplication
WaveDashboard
WaveDataflow
WaveDataset
WaveLens
WaveXmd
WaveTemplateBundlePlease consider adding this to the roadmap for immediate consideration!
Best regards,
Mike1 voteThis has been shipped and we’ve written up an overview of the feature: https://gearset.com/blog/gearset-and-einstein-analytics-deploy-wave-applications-with-ease
-
create branch
It would be nice to be able to check Salesforce changes into a new branch in Github (or other git repos). This would provide admins an easy entry point for their changes into a git repo without having to learn the esoteric git command structure.
2 votes -
A way to view failed deployments from Gearset
Right now if a deployment fails in Gearset, it doesn't show up anywhere within Gearset; it just sends you an email. It would be nice to have a place to view failed deployments and retry them (maybe it only failed because the environment was locked), just like you can with successful deployments in Deployment History.
3 votesGearset now shows failed deployments on the deployment history page: https://app.gearset.com/deployments/deployed
-
Ability to pause CI jobs
Ability to pause a CI job. This would allow the CI system to keep our sub environments (stage, dev, beta) updated all the time, but when we want to develop on one of them we could then pause the CI job so our changes don't get deleted. Then once we have deployed the changes to prod we can reactivate the CI job to keep things in sync.
5 votes -
Run external tools like PMD as part of Schedule Tests/Monitor Org
PMD tool that does apex code 'quality' measurements would be kind of cool to run (optionally) as part of a regular monitoring/test job. This could be generalized to any external tool
1 voteGearset will now run PMD to track code analysis as part of the Monitoring and Backup flow. The plan is to roll this out to other parts of the app so we can more easily track the change in code quality.
-
Add the ability to define which Apex Test's are run during the validation phase of a deployment
I would like to suggest a new feature request. We have a great need to define which apex tests are run against the Target ORG due to special configurations. We have apex classes / test classes that are created in Target ORG's that are client specific. For example, if we go to deploy our managed package from Sandbox A -> Sandbox B, the tests may fail since the content in Sandbox A needs to get to Sandbox B before the client specific changes can be updated / tested. There are multiple parts to our product and adding in the ability…
2 votes -
CI Jobs - Partial Deployments
Allow partial deployments when changes are committed into a branch, so instead of trying to re-deploy the full repo, we should have an option to allow deployment for only the changed items.
6 votesCI jobs can now be set to deploy only certain types of metadata change: new, changed, deleted. If only “changed” is selected, no new metadata or deletions will be pushed by the job, only modifications to metadata that exists in both source and target. This selection is found in the job creation/edit screen. You can also specify whether you want the CI job to respect a package.xml file when deploying from a repository for even finer control over what metadata it deploys.
-
Create CI deployments which only run on demand
Have jobs that run only manually, rather than on time or commit basis.
Specify the source and target and the metadata filter, and save as a preset job. The job can then be triggered to run on demand with a "Run now" button. This means we can safely update our branch until ready to deploy, then don't have to manually compare orgs to push the changes out1 vote -
Text results on Monitoring to multiple phone numbers
Allow text message notifications to multiple phone numbers
3 votesYou can now add multiple phone numbers to receive text notifications for Monitoring and CI jobs.
-
Exporting Scheduled Test Results to File
We would like to see the ability to export the scheduled test results to PDF or Spreadsheet. This will allow us to associate test results with our internal work items and allow visibility into the test results. I understand that users can view the test results with no license. However, i see value in having the export available; similar to the export of the deployment report.
1 voteYou can now export test results as an Excel file from the test run history by clicking the Excel icon.
-
Edit CI Filters on an Existing Job
Be able to adjust the filters for a CI Job that is already running. Currently you would have to delete the job, adjust the filter, and then setup the job again.
2 votesWe’ve now added the ability to edit CI filters on an existing job.
We’ve also added:
- see currently running CI jobs
- Manually kick off an existing job instead of waiting for the schedule to start -
Have CI jobs work using BitBucket webhooks
Just like it is already with GitHub.
1 voteSupport for Bitbucket webhooks for CI jobs is now live if you want to test it out.
Stephen
-
Ability to create CI jobs from GitHub Enterprise
I expect parity between GitHub and GitHub Enterprise when it comes to creating CI jobs and CI jobs with web hooks.
1 vote -
Allow teams to share custom filters
Allow those filters we can save to be shared amongst our team!
7 votesCustom filters are now automatically shared with other members of the team and can be selected from the saved filter drop down when setting up a comparison.
Blog post on usage: https://gearset.com/blog/shared-team-comparison-filters
-
Custom login URLs
We deal with SF instances that do not login with the standard login.salesforce.com or test.salesforce.com.
It would be nice to see an option for custom domain or custom url that can be used for either OAuth or username/password authentication.
2 votesThanks for the feedback!
This was shipped today – on the comparison screen you can now add an org with a custom domain by selecting “My Domain (Government Cloud)” from the Salesforce authentication type dropdown. This works with Government Cloud orgs, and also any Salesforce org that has a custom My Domain url.
We don’t currently support My Domain orgs with username/password authentication. Please let us know if that’s a problem for you, or if the feature doesn’t work as expected.
-
Allow GitHub to be a Target, not just a Source!
Let us move changes to GitHub!
5 votesWe’ve now shipped the ability to choose GitHub, Bitbucket and GitLab as the target for deployment.
Simply pick the Source Control option on the target when configuring the comparison.
-
Support v37 API Metadata Items
I'm unable to deploy metadata items that were introduced in v37 of the API.
1 voteWe’ve now migrated to v37 of the API.
- Don't see your idea?