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.
165 results found
-
Manually Delete Metadata after CI job runs
We don't want the CI job to delete metadata, so we've unchecked that box. However, when a CI job runs that would have deleted data, we'd like to be able to select from the job history, review what would have been deleted and elect to deploy the deletion manually post CI run. We can re-run the comparision from Compare and Deploy, but having this action tracked within the CI job history would be more convenient, and would allow the history for the target org to be contained in the same thread.
2 votes -
CI Deployment on a Schedule
We would love to schedule a deployment from GitHub source to a few sandboxes at the end of each 2-week sprint.
2 votes -
Allow Deployment Notes to be editable post-deployment
Allow Deployment Notes to be editable post-deployment. Our team uses very specific notes for auditing purposes, and being able to edit them post-deployment would make that process a lot easier for our teams.
2 votes -
Filters
Edit "Existing Saved Filters" on an "Existing CI Job"
If using a saved filter on CI job, there is no easy to update an existing saved filter from the CI job directly.
2 votes -
Granular "difference types to deploy" on a metadata level
In the CI job, we would like to have the ability to specify on a metadata level if we want to deploy new items, update items and delete items. There are examples of metadata where we always want to delete and others where we don't want to.
2 votes -
Add option to provide exact time in case automatic deployment
We need to set exact time for automatic deployment. We need this option for example for night releases for specific client. This is important for international clients that works in different time zones
2 votes -
Add the ability to order/chain overnight jobs
Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.
it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:
- Monitoring Snapshot
- CI run
- Unit testing
This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.
Ideally, we'd be able to do this without just specifying exact times to…
2 votes -
CI/CV job archiving
Create a mechanism by which CI and CV jobs can be archived, but not deleted. Sometimes there is a job that is not used, but the history needs to be kept for some period of time.
2 votes -
Allow Source to choose multiple Branch for CICD Validate/Deploy
when choosing source as GitHub it allows user to choose feature/*** which allows every commit on branch name starts feature will trigger the CICD
2 votes -
Deploy on pull request creation
Currently is supported only validation on pull request creation. It would be great if we can also do deployment on pull request creation, not only on merge.
2 votes -
Automatic retry for Unknown Error in scratch org creation
When creating a new scratch org from either the Gearset UX or via a CI job, one often gets the Unknown Error message
Gearset should attempt to retry this error as often, a simple retry works. This is especially important for CI jobs which should not have to be attended to manually.
Of course, the better solution is to not get this error at all
2 votes -
Allow setting the default testing method for deployments
I want to enforce that any deployment into a UAT sandbox runs all the tests. The standard Default option runs no tests since it's a sandbox. I have to manually choose the "Run Only my Tests" Option every time I deploy to that sandbox. I would like to be able to have that option selected by default
2 votes -
Save draft deployment notes
Save draft deployment notes so when you combine drafts you can see all the notes from each single draft
2 votes -
Ability to carry out action after successful deployment or detect org changes (monitoring)
After every release, we have to do smoke testing. We do have automated testing using selenium and we wanted to trigger the automated testing every after release is detected. It would be nice if in the deployment we can call an api or webservice after successful deployment. Or in the monitoring we can call an api when there's a change happened in the org.
2 votes -
to add an option to not to run unit tests validation in CI job in case there are no changes detected
2 votes -
facilitate selection at the UI of related permissions for selected items during deployment
Our typical use case surrounding related permissions for selected components (application visibilities, class accesses, field permissions, layout assignments, object permissions, page accesses, record type visibilities, tab visibilities) is to need to ensure that if a component is selected, its related permission is always selected also, with respect to a target set of profiles. We suggest you provide an affordance at the UI that selects related permissions en masse rather than requiring individual mouse clicks for each permission selection as at present.
2 votes -
Webhook trigger when Pull Request is Completed in Azure DevOps
Continuous Integration job to trigger when a Pull Request is Completed in Azure DevOps
2 votes -
Add an option to disable deploying the email to case settings in Case.settings
This will allow to deploy Case.settings without getting this deploy error:
EmailToCaseRoutingAddress[Info]: emailServicesAddress is a read only field and cannot be changed2 votes -
display meta data filter used on deployment report
It would be useful to see the meta data filter used on the deployment successful report
2 votes -
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.
2 votes
- Don't see your idea?