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 -
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
-
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.
-
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
-
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.
-
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.
-
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.
-
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 for the ability to "lock" a metadata filter in for a CI job so that the CI job has any changes to filter.
Currently, the CI job takes the current metadata filters settings but does not used the updated settings. You have to re-add the filter back to the CI job. If checked on the CI job, the job would use the current filter's latest changes rather than the ones it was created with.
1 voteYou can now edit the CI job and choose to simply refresh the filter list so it grabs the latest changes to any of the filters and as a result will let your CI job use the most up-to-date settings.
-
Change CI Job Design
Your new CI job design is horrible. I use disabled CI jobs as one button deployments. You've just doubled the number of button clicks I have to do for no good reason. Run Job should be on the main bar.
1 vote -
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 -
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
-
Allow editing all CI Job Fields
One should be able to edit all the fields on a CI Job, especially the source and destination fields.
2 votes
- Don't see your idea?