Help us improve Gearset
Welcome to the Gearset feedback forum. We love getting feedback from our users on how we can make Gearset even better.
Post your ideas and vote for others – let us know what’s important to you. We’re keen to hear about product improvements, new features, and bug fixes alike. We check this forum regularly and will keep ideas updated with their current status. If you need any further support, please contact us at team@gearset.com.
-
display meta data filter used on deployment report
It would be useful to see the meta data filter used on the deployment successful report
1 vote -
Allow CI deployment notifications to the specific user who made the source control commit that prompted the deployment
We have CI jobs that fire on commits to a source control repository. At the moment, there is no way to email the specific individual who made the commit that prompted the deployment, so we have to notify everyone involved in the project whenever a deployment fails. If we could just notify the individual who made the commit (plus the deployment manager), it would reduce noise considerably.
Please add this feature.
12 votes -
allow a method to set up default branches.
I frequently deploy from our on premises GitLab repo. It would be great to have the ability to set the default branch it goes to. It would be one less click for repetitive steps
5 votes -
Display a custom name in Salesforce when deploying from Gearset
When we deploy a change to one of our Salesforce orgs using gearset, the name that is displayed in the "Deployment Status" in Salesforce is an ID. It would be helpful to display the name that we entered in Gearset instead of the ID so that we can easily identify the changes when looking at them in Salesforce
6 votesHi,
We have recently investigated adding this feature again, but unfortunately Salesforce still don’t seem to support being able to display custom names via the Api (or it’s a feature that’s not well documented). There are requests for adding this ability via:
https://success.salesforce.com/ideaView?id=08730000000cJdxAAE
If the situation changes then we’ll certainly revisit this. We’ll keep this post opened for other users to also add their votes but it’s currently out of our hands as to when or if it can be added.
Regards,
The Gearset Team
-
provide creation of immutable deployment package
I would like a way for Gearset to create an immutable deployment package that can then be deployed to different orgs. This immutable package should contain a copy of the selected objects, list of unit tests to be executed and not allow variation in the deployment except selecting the target org. This would also save time by not requiring a new comparison to run for each target org.
1 vote -
Show the commit message with the Commit ID on the CI History Screen
The CI Job History Screen would be much more useful for me if it was able to show the commit message on the commit that triggered the CSI alongside the source commit ID.
3 votes -
2 votes
-
Add the option to purge on delete
The metadata API has a boolean option to "purge on delete", i.e. permanently erase deleted items rather than just moving them to the recycle bin. This option is not exposed in Gearset currently, but rather hardcoded to "false". For CI scenarios in particular, it would be extremely helpful to be able to specify that this option should be set to "true" for deployments.
1 vote -
Allowing data deployments in CI jobs
Allowing data deployments in CI jobs. So that configurations in third party apps and B2B Commerce can be deployed as part of CI.
5 votes -
See Continuous Integration Deployments in the Deployment History tab
List deployments resulting from a CI job on the Deployment History tab along with manual deployments.
We currently deploy metadata using both manual and CI jobs and it would be convenient to see all deployments in the same list (for debugging, reporting, monitoring).
2 votes -
Run test in parallel using scratch orgs
CI job that run all test takes ages. Can we use scrach orgs and test suites to run test in parelell in multiple orgs?
https://developer.salesforce.com/blogs/2018/06/running-tests-5x-faster-using-sfdx-and-heroku-ci.html1 vote -
Support parallel testing during CI job
CI jobs use metadata API to deploy and run tests. The tests run serially. As such, CI jobs can take many minutes to execute
As an optional configuration for a CI job, and only if the CI is run against a non-PROD org...
- Deploy metadata using Metadata API
- Run tests using Tooling API (parallel testing)
- If tests fail, use MetaData API to rollback the deployment
Ideally, this can shave off 50% of the CI job time
3 votes -
Extend the ability to add and delete in a single deployment to all metadata types
We just came across an issue in which we were deploying an HTML email template that had been moved from one folder to another in the source environment.
When deploying, only the delete happened on the first deploy. I needed to do a second deploy to handle the addition.
While probably not a common case, it's certainly important as the initial deployment reports that the addition was successful.
1 vote -
Create a Master-Switch Only deployment process
Can you create a master-switch deployment option? It would be similar to how this operates: https://sfswitch.herokuapp.com/
The issue is that this master switch does not always work with managed packages in production orgs.
So a way to automate the turning off/on of Validation Rules, Process Builders, Flows, and Triggers.
Use Case: We are building a new app and have significant data migration to do. It would help to have a master switch to turn off processes in PROD, deploy date, then, flip the master switch back to turning processes back on.
2 votes -
Add Run all tests except .... configuration in CI job
Our CI jobs take way too long (1000+ tests) despite heroic efforts to use ApexMocks. As our org contains a bunch of unmanaged packages with known class name prefixes, and these constitute at least 10% of the total tests; we could get back 10% of our life if we could exclude these from the "run only your tests"
For example, we would want to exclude running any tests in classes that start with "fflib" and "sfab"
A variation of this would be to run a specific testSuite and it would be our responsibility to keep the testsuite up to date
1 vote -
Allow (restricted) editing of source XML to add deployable properties that can't be fetched via Metadata API
Example:
It is impossible with OOTB Gearset to deploy an autonumber field with a starting number and optional populate existing rows. Why? Because the SFDC Metadata API as of V42 doesn't allow fetching of these two properties of the CustomField object:<populateExistingRows>true</populateExistingRows>
<startingNumber>1</startingNumber>Once in source, they'll deploy just fine to the target org. Note that changesets support this feature.
The workaround, which is to deploy to target branch and then edit target branch is sort-of-OK but it would be nice to modify this in the source. Of course, if you Refreshed Comparison, your edits would be…
1 vote -
Ability to add custom trigger points to trigger CI from source control
At the moment the tool allows you to only kick off CI jobs when a branch is updated.
This is actually limiting the capability of the tool in itself,
because services like Bitbucket allows you customize trigger points, as to when they should ping the webhook;
such as the creation of pull request, merging a pull request.The two trigger points mentioned above are specifically very important because you would want to run validation CI jobs on the creation of pull request or when the merge completes so that you can actually ascertain if your branch compiles.
Based on an…
11 votes -
Allow repeat/redo deployment from Deployment History
Use case:
- Deploy from source to target
- Some testing (or possibly PR review) in target requires fixes to be redeployed from source to target
Currently, you either do a new Comparison or clone the Deployment and re-enter the source and target. In either situation this is tedious.
Why not add a "Redo" button on the Deployment History that uses the same source/target? Place it next to the Clone button?
Or, in the Clone button, default the source and target to the same as the selected Deployment? (which would also be useful)
1 vote -
Filter Notifications for Non-CI Deployments By Successful or Not
When I do a deployment that is not a CI deployment, it can send an email. But the email goes out regardless if the deployment is successful. I would like to be able to send the email ONLY if the deployment is successful.
1 vote -
Reuse Deployment Package (clone) should use sticky "Source Repository"
Use case:
1. Compare and deploy from repo-R/master to org A
2. Clone deployment from repo-R/master to org BUnfortunately, when the clone deployment displays the dialog "Reuse Deployment Package"...
a) When you select GitHub, the dialog doesn't default the repository to Repo-R but instead displays a picklist of all possible repos the running user has access to (in our case that is 100+)
b) Better would be to remember in cookie the repo the developer last used and default to that choice so scrolling through 100 items is not necessary.3 votes
- Don't see your idea?