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.
1240 results found
-
Summary pages should always include ALL changed files
I believe this to be a bug, but it might be intentional. In any case, the current functionality is, in my opinion, poorly conceived.
If a user adds a deletion to a comparison between an org and git, the deleted metadata is the only item that will show up in Gearset. However, if you inspect the resulting commit in git, you will see that the metadata was deleted along with all of the profiles, layouts, etc that had to be changed as a side effect.
I'm completely fine with Gearset detecting these dependencies and making the changes to them. It…
1 vote -
Autodeploy on git branch a successfully manual deployment on org
When a developper deploy a new feature on a sandbox it will be perfect if the deployment can be auto deploy on a branch git (and copy the deployement note, etc).
Today I use a CI job backup on the sandbox but we lost the deployment comment + the updates granulartity.
We could use also the "Clone Button" on the result deployment page but it's lost time to relaunch the comparison and the different step etc while we want exactly replicate the deployment.
1 vote -
When CI jobs fail with "admin operation already in progress", retry the CI job automatically
I was informed in my slack integration today that my CI job failed with an error message of UNKNOWN_EXCEPTION: admin operation already in progress See https://app.gearset.com/failed...
I would like to see Gearset automatically identify this type of error as something different than a metadata error and then retry that CI job 3 times over the next 90 minutes (for example). It would be fine for it to stop after those 3 successive failures.
1 vote -
1 vote
-
Provide the ability to run static code analysis on all commits to the repo
We'd like the ability to run static code analysis on all commits to a repo, regardless of the branch name. This would allow us to catch code quality issues early and up front, regardless of the branching model we use.
Example: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (development is done in feature-* branches, so there's no one branch we can configure a CI job on)
1 vote -
Gearset to do Sanbox Refresh by copying metadata and data from production
Quite often an Environment needs to be refreshed, but every time it happens all the integration breaks as OrgId changes. Gearset can move metadata and data, which when made together can be a solution for sandbox refresh. Full copy sandbox sometimes takes days, GS will be able to it quite quickly.
1 vote -
Preserve auto-number field values during a data deployment
Staging environments typically exist with integrations with other systems that have references to auto-number fields
Data deployment re-evaluates auto-number fields instead of keeping the values of the source.If data deployment jobs could automate the following it would probably work
1. changing the type of the auto-number field to text in the target org
2. potentially removing apex references to the field
3. deploying the data
4. rolling back metadata modifications in steps 1 and 21 vote -
Allow searching for Org IDs in deployment history
Enable the search results in Deployment History to include Org Ids.
USE CASE: I want to see a history of all deployments into, or out of, a specific org, regardless of the usernames used to deploy.
BONUS POINTS: allow me to specify whether it's the ID of the target org or the source org when searching. ex -
targetorgid:00D1U000000sfXD
sourceorgid:00D1U000000sfXD1 vote -
enumerate unsupported metadata in Manage Custom Filters
In Manage Custom Filters dialog, Gearset should link to
a) https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm
b) a Gearset list of Metadata API-supported but not yet GS-supported metadata typessaves devops person wondering why certain metadata can't be deployed
1 vote -
update the wording in the change notifications - objects created sounds like Salesforce objects, not individual items
We run change monitoring and were very surprised to have 218 Objects created in Production over the weekend when no one was working. It would be good to rename this to 'items' instead to make it more clear.
1 vote -
push new profile FLS entries into the profile file in alphabetical order
When picking up new FLS entries, by default these are added at the bottom of the list of FLS.
This causes issues when also having save jobs picking up changes, as this can result in duplicate FLS being added to a branch.
Please update code structuring, so new FLS is added in the correct place in the MD files.
1 vote -
Approval requests for CI deployments
It would be great if there is an automated approval process to deploy the code to higher environments. If there is a button "Submit for approval", and an email sent out to approver. that we can setup. once approved, a CI job need to run and deploy the changes to next environment.
1 vote -
Don't allow duplicate fields in comparison.
If I have a field with name example category. Somehow the same field has been added to the object xml file it needs to throw an error at the time of comparison.
1 vote -
Create a way to apply a regex to all currently selected metadata types when building a filter
The regex support you currently have doesn't really allow for complex (multi-match) regex matching, which is probably ok. (this would be something like grep -e 'this' -e 'that')
If I select, say 116 of the 124 metadata types identified, and then have to apply a regex pattern to each one, it gets pretty tedious. Click-paste-apply 116 times, and then 116 again for the other half of the complex match. I'd write a tool to automate configuring a filter in gearset. :)
If I "select all" then deselect the 8 types i don't want, and THEN apply a regex to all…
1 vote -
Allow filtering by Deployment Stage/Metadata Subset during comparison
This Gearset article describes some very logical phases for performing a large deployment:
https://docs.gearset.com/metadata-deployment-guides/splitting-a-complex-deployment-into-stagesIt would be nice if there were built-in comparisons to show each subset of metadata.
For example if you were on phase 1 of the deployment you could filter your comparison to just "Data Tier" and Gearset would pre-filter the relevant metadata.
1 vote -
Add functionality to select the changes in the component for the deployment.
I think it will be very helpful to have a possibility to deploy only some selected changes in the modified component.
1 vote -
Badge
To have he possibility to have badge that could be added to the readme of a git repo. Display in green if the test classes have been successful, red if error.
The same kind of badge could be used for deployment.1 vote -
When viewing comparisons, allow the "Export All..." to utilize existing filters
When viewing a comparison... I have various filters set to exclude certain differences like "Reports, "Permission Sets". It would be nice if you provided an option on the "Export All..." page to either export everything (disregard filters) like it does now, or to respect any filters that currently exist on the comparison so that I only see the values shown on the page based on my filters.
1 vote -
Retain Link to JIRA Tasks When Combining Deployments
Part of our release management policy is for all deployment to be associated with JIRA tasks. I noticed that when cloning individual deployment the association with JIRA tasks is retained. However, when combining multiple deployments, the relationship with JIRA is broken and as a result, we need to re-associate each JIRA task back to the combined deployment package.
1 vote -
Allow retrying failed validations and deployments
I'm often running into the situation where the validation failed either due to transient circumstances in the org, or due to the org settings being incorrectly configured. In this scenario, I would like to simply retry the validation using the same package, and I'd look for that option somewhere here:
https://app.gearset.com/deployments/validations
Running a new comparison (using the "clone package" option) is unnecessary, takes a lot of time. Also using the "view comparison" option is overkill. I would rather not go through those motions of recalling the comparison results from cache, going through the analysis once again, etc. Because I know…
1 vote
- Don't see your idea?