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.
81 results found
-
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.
-
Add BitBucket Integration
Would be awesome to have the equivalent of GitHub and GitLab for BitBucket!
1 voteWe’ve now shipped Bitbucket support in Gearset.
-
Add support for GitLab
Like the integration with GitHub, to compare and deploy from repos to our Salesforce orgs.
2 votesWe’re happy to say we’ve now launched GitLab support from within Gearset. You can compare and deploy straight from your GitLab repos to your Salesforce orgs.
-
Option to run tests when deploying to dev or sandbox orgs
You run tests when deploying to production orgs, which is great, but sometimes I want to force tests to be run when deploying to sandboxes or dev orgs. Can you add in an option to run tests for these orgs?
1 voteThis has now been shipped. You can choose whether or not to run tests when clicking the deploy or validate buttons.
-
Deploy from change monitoring result
It would be great to be able to deploy changes detected in a specific change monitor result from the report history. Either to roll them back if they are unwanted, or deploy them to other orgs to replicate them into dev boxes.
0 votesWe think there are two parts to this request.
We’ve now added the ability to roll back changes from a change monitor result – you can selectively remove any changes made to that org on a daily basis by comparing from a snapshot to live state.
We’re now working on adding support to clone a detected change and deploy it to other orgs. This would let you push changes made in Prod down to a Sandbox, for example.
The second part of this is contained in another ticket, so we’re marking this one as completed.
-
Deploy to source control
It would be great to be able to deploy changes to my source control system, as well as from them, from the hosted app.
0 votes
- Don't see your idea?