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.
31 results found
-
Improve the doc page: Fixing a feature that’s halfway through the pipeline
The procedure as written seems complex and counter-intuitive
Given that a developer sees the process as DEV->Integration->UAT, if an error is detected in UAT manual or automated testing, the fix should flow from DEV -> integration -> UAT.
But the article has the fix going from DEV->UAT and then back propagations back to Integration plus manual PRs created in VCS. This seems way too complicated and hard to understand for a mere admin or junior dev
1 vote -
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.
-
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."
-
Clone CI job without delta enabled
As the Gearset administrator for my team I want to be able to clone a CI job that is set as a delta job without the delta flag enabled so that I have less effort to create a brand new CI job.
Acceptance criteria:
- When closing a CI job with the delta flag enabled, give the option for the new job to now have the delta flag enabled.
- If the source and target are the same as an existing job, provide a visual warning of the potential consequences of replication of the job.
1 voteHi, this feature has now been released.
When cloning a CI job with delta enabled, you should now be able to toggle the delta CI checkbox when configuring the cloned job -
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?
-
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
-
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.
-
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.
-
ci owner
Allow CI jobs to be reassigned to new owners. Or allow for out of office functionality when CI Owner is out of office.
1 voteCompleted on March 6th, 2020 see documentation on https://docs.gearset.com/en/articles/3758806-transferring-ci-job-ownership
-
Update package.xml with destructive changes which helps CI jobs
When I commit components to bitbucket brach if I have 5 new components and 5 deleted components. then Gearset is updating package.xml in the src folder with only 5 components which are to be created but destructive changes are tracked no where. Then if we deploy from this branch changes to Sandbox using CI job which has 'Filter metadata changes using package.xml' checked, then the deleted components will not be deployed. It is good if Gearset give a feature to track destructive changes and deploy using CI job.
1 voteCompleted on October 29th, 2020
-
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.
-
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.
-
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.
-
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 -
Github Pull Request as a `Draft`
This new feature is great. Would be even better if you can select that the PR be a draft.
1 voteHi,
You’ll now see the option to create a draft pull request in GitHub, if your repository supports draft pull requests.
Draft pull requests are available in public repositories with GitHub Free, GitHub Pro, and legacy per-repository billing plans, and in public and private repositories with GitHub Team and GitHub Enterprise Cloud. For more information, see https://help.github.com/en/articles/about-pull-requests#draft-pull-requests.
-
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
-
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
-
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 -
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.
-
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
- Don't see your idea?