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.
35 results found
-
Allow other Enterprise Users who do not own the CI Job to run it
Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.
46 votes -
Commit-by-commit deployment
As you are giving an option to trigger the CI job based on repository commit, it would make more sense to only compare the source and target based on the commit items and consider the commit changes for deployment based on your selection of either new, modified or deleted and the comparison filter(which can be optional in this case).
This will help in reducing the chances of overriding the changes of other teams working in a shared environment or an environment not in sync with the branch.
There can be other scenarios where we maintain managed package items in the…
43 votesThis was released on the 23/03/2021. Documentation is on https://docs.gearset.com/en/articles/5069914-delta-ci
-
Combine multiple deploy packages into one
It would be nice to have the ability to select multiple packages in the deployment history, and clone all of them into one comprehensive deployment. This would help when there are multiple features moved at different times to a QA environment, but would like to move them all at once to Production.
28 votes -
Rollback deployments made by CI jobs
Manual deployments and change monitoring jobs can be rolled back. Add the same function to CI jobs in case it accidentally deploys something unwanted
27 votesWork completed on December 22nd, 2021
-
Allow CI to do a quick deploy
Allow gearset CI to do a quick deploy either by default or via a setting on the Job definition.
Our tests run for nearly 90 minutes and are currently run twice in succession causing a lot of frustration. Once when a PR is validated and then when it is merged and deployed.19 votesThis functionality is now enabled automatically for CI jobs with the "validate pull requests targeting the branch" feature. This means Gearset will automatically try to quick deploy the package after the PR is merged meaning that tests don't need to be re-run. There is no need for users to change behavior and CI jobs will run and look as normal
-
More granular control over CI job schedules
Currently, a CI job that deploys from a Salesforce Org to another org or source control can only be scheduled to run at 4 hours intervals. Additionally, there is no mechanism of specifying when these jobs will run - instead, the job is scheduled randomly within the first 4 hours it was created and every 4 hours after that point.
Providing a smaller interval (ex. every 1hr) and/or more granular control over the job execution time seems like a common sense enhancement.
14 votesYou can now set the interval to every 1 or 2 hours. Can you see is this matches your request?
-
Add a Save As to Save Draft Deployment
Add a Save As or an alternative way to create multiple packages from the same comparison. I have an existing comparison run and I want to stage the deployments, deploying some today and the rest next week. It would be more efficient to save both packages now as I am going through them, saving one for example as Dep120916.1 with half of my selected object and another one called Dep120916.2 with the remaining objects to be deployed later.
13 votesFrom the results page, you can now select the Save as option from the button toggle menu.
-
Add the ability to set Metadata filters for all Pipeline environments at once
In order to update the metadata filters in a pipeline, one must individually update each environment's metadata filter from the list of Continuous Integration jobs.
It would be amazing to be able to set a metadata filter in the pipeline and have it propagate to all environments in the pipeline.
12 votesThe way metadata filters work in CI jobs has been updated. Changes made to a shared custom filter will now apply immediately to all CI jobs where that filter is used. This means a single filter can be used to manage multiple CI jobs. Check our documentation for more information.
To adopt this, head to your CI jobs, select the filter you need, and hit save in all of them.
-
To make it possible to abort started CI job on Continuous integration dashboard.
At the moment, you need to wait until the comparison is finished and the deployment has been started and then you should go to the org to cancel running deployment. It would be useful to have an option to abort the CI job.
11 votesThis feature is now available with the latest release.
-
offer the capability to exclude items in a metadata filter using a regex pattern
If we can exclude certain things in the comparison filters, all other newly created things are automatically provided with the CI job that uses my comparison filters.
For example, at the moment in "custom filters", if I select the type "custom object" and disable "all elements", I can filter and choose which objects we want to compare.
-> We need the option to invert the filter. To be able to select the specific objects that do not want to compare and deploy (like "Not: regex: waste_ | QA_ | staging123_").
11 votes -
Ability to run a Validation only CI job on a pull request - this will make pull request ready for deployment without error
- Developer creates a pull request to a branch
- CI job validates the pull request and notify in case of errors
- Developer corrects errors - CI job again validates the pull request and this time it is fine 4.Release manager merges the pull request to the branch specific to an org and CI job deploys without error.
9 votesWe now support validating pull requests from GitHub, GitHub Enterprise, Bitbucket, Bitbucket Server, GitLab and Azure DevOps.
-
Be able to edit the CI sync frequency
When creating new CI job from one Salesforce org to another, there is no way to edit the frequency of synchronization. It would be useful to make a change so that integration is done less often than every 4 hours
9 votes -
Include/exclude individual metadata in templates by managed package
The Include Managed Packages option right now is a global one-- and, while nice, that doesn't cover situations where you want some metadata of a Managed Package (eg. a Profile permission) to be included, but not others.
Currently users have to laboriously deselect data related to Managed Package in certain areas (eg. Static Resources, Permission Sets, Custom Tabs) because it'll always fail to deploy.
The ability to include Managed Packages for some metadata, but not others, in templates would solve this issue.
9 votesWith Gearset’s named filters, you can now configure exactly which metadata components are going to be included in a comparison.
For the advanced use cases, you can also use regular expressions to define rules that, for example, include all managed components that match a certain naming convention.
You can find the docs on our site https://docs.gearset.com/feature-guides/comparisons-and-deployments/custom-metadata-filters
-
Create the ability to migrate components to new source and target orgs after having in a Saved Drafts.
When saving components into drafts, when validated, we would like the ability to be able to migrate the same components into new source and target orgs.
8 votesHi,
You can now use the new clone feature for any saved draft deployments if you’re an enterprise tier user.
Regards,
Stephen
-
Be able to create a CI Job with the option to validate only (and quick deploy later).
For the case where users have committed changes to a "master" branch, it would be useful to automatically run a full validation on the new commit in the Production environment. In that way, a deployment manager can review the changes and quickly deploy a validated package that has passed all tests in Production.
7 votesHi Nghi,
We’ve added the ability to review and deploy a validation CI job.
Catherine
-
Partial environment variable replacement and wildcards
Some types of metadata, such as Platform Event Subscriber Configuration, have attributes identifying a user by username. As such, regardless of the value in the source environment, the value deployed to the target org must match the username pattern of that org.
For example, if the value in the source repo is <user>name@example.com</user>, when deployed to a sandbox, it must be <user>name@example.com.sandbox1</user>. From sandbox to sandbox: <user>name@example.com.sandbox1</user> must become <user>name@example.com.sandbox2</user>. And finally, when going from sandbox to production: <user>name@example.com.sandbox1</user> to <user>name@example.com</user>.
This could be solved by supporting environment…
6 votesYou can now use Regular expressions in the "Find what" field when defining environment variables, allowing you to do wildcard/partial replacements.
-
Add ability to Ignore Warnings to avoid treating Salesforce warnings as errors
See IgnoreWarnings parameter: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm
6 votesWe have implemented this feature now. To toggle the setting, navigate to My Account (using the dropdown next to the Gearset logo), then Salesforce deployment.
-
Scratch orgs - Create a new scratch org with more than one package
During the creation of a scratch org the system doesn't allow the installation of more than one package...so after create a scratch org we need to install manually the remaining packages.
6 votesYou can now install more than one package when creating a scratch org.
-
CI dashboard: Show commitId when job is in flight; Show queued commitIds
On CI Dashboard page, a CI job in flight (deploying/validating) should show the commitId that triggered it (if any) PLUS show all pending CI jobs.
Reason: If two developers are sequentially merging to a shared branch tied to the CI org (and webhook is setup to run immediately), then the first developer's merge starts CI job 1 while the second developer's job is queued.
Yet, from the CI job page there is no way to even tell which commit to the branch is running (so as to clue the developer that his/her job is running vs queued. Commit message would…
3 votesThanks for the suggestion! When a CI job is running from git, the commit hash and the commit message is now visible for all git providers. In addition, for GitHub, Gitlab and BitBucket sources, a link to go to the relevant commit will be displayed.
-
Allow users to specify when to apply Environment Variables
A good feature would be to have some setting that lets you declare when you should apply environment variables. Since right now it is applied automatically during manual deployments and CI deployments. Perhaps in the wizard when you configure deployments there should be some option there to declare if environment variables should be applied or not?
We have some Custom Metadata and Custom Settings that always need to be updated post-refresh based on the new sandbox instances and it would be useful to use environment variables to set these values and deploy them one-time without them being deployed in every…
2 votesEnvironment variables will only be applied if its configuration as specified by the user (metadata type, item name, and a field for some types) matches the type and item name in the deployment package.
In all other cases, environment variables won't apply.
Added clarification in the Environment Variables config page:
"Environment variables will be applied automatically during both manual deployments and continuous integration deployments if the metadata item is included in the deployment package."
- Don't see your idea?