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.
134 results found
-
Expand the options for "Run job" times on the continuous integration job setup.
Currently the "Run job" option has times for 1, 2, 4 and 24 hours. With international teams working on projects, it would be nice to allow for something like every 8 hours. That could either be a new set option in the list, or allow for a "custom" option. If the pipelines can handle between 1 and 24 hours, let us selection "custom" and input the hours for the job interval to run.
5 votes -
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…
4 votesThanks Mike for submitting your idea.
Gearset's Environment Variables feature already supports partial string replacements, which means you can get Gearset to replace 'sandbox1' bit of the <user> tag value with 'sandbox2', as follows:
Target: Sandbox2
Metadata Type: Platform Event Subscriber Configuration
Item: Any item
Find: sandbox1
Replace with: sandbox2
-
Feature vs Release, Branch De-sync
When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.
Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.
Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the…
1 vote -
Pipeline CI jobs where deployment is disabled should capture validation job history
If you have a Pipeline CI job configured to be Run Job = disabled; you can still promote PRs and run validations (which is great). But the validation job history is not preserved under the CI job. In fact, AFAIK, it can't be found at all except for the current promotion's vcalidation
This would enable one to diagnose validation fails - perhaps due to problem analyzer automations. It would aid in communicating with support (as such validations could be shared)
2 votes -
Sort or Filter Active CI Jobs
Currently, there is no great way to filter out old/inactive CI jobs from the Active CI jobs. This poses a problem as there are situations where we have replaced CI jobs in the past, or created/disabled test jobs. Currently they clutter up the Continuous Integration Dashboard, but it would be nice if we could hide them so we don't have to delete them and lose their history.
1 vote -
Local Metadata ignored if name collides across an unlocked package namespace
Current Behavior:
During PR validation of an lwc component named "utils", Gearset reports no changes and runs validation against target org with 0 components because there is a Namespaced Unlocked Package in the target that also has an lwc component named "utils". This can be seen in the "Problem Analysis Results" within the Validation Details for the PR.Expected Behavior:
Gearset should not diff my local components against components that are behind a namespace. Even when those namespaced components are in an unlocked package. Perhaps Gearset should treat namespaced unlocked package components more like managed package components.This is related…
2 votes -
Schedule Delta CI Job to Run at Specific Time
I would like the ability to schedule a Delta CI Deployment Job at a specific time. We have a requirement to deploy at weird times every once in a while.
Code gets merged into our MAIN branch > Delta CI Deployment Job is disabled > click "run" on the job at specific time.
It would be great if someone didn't have to wake up at 3am to click the "run" button.1 vote -
Option to set and make use of 'deployment rules'
It would be great if we can have the option to set and make use of 'deployment rules':
1 - receive an alert/warning message (in gearset/via email) right before deploying to a selected target environment, for instance - a production environment if certain pre-defined metadata types are included in the deployment.
use cases: a reminder to run all test when deleting metadata, a reminder to activate a flow on target environment after deployment.
2 - block a deployment in the following case scenarions:
a - if the deployment of certain pre-defined metadata types happens within a pre-defined timeframe.
use case:…
8 votes -
"Sync environment" automation
On the pipeline, the action of "Sync environment" is currently a manual action. It could be useful to have an automation of this action (like the back-propagation) after each Production Deployment. This step is a little bit time consuming and can be easily missed. If we had an automatic creation of this synchronization PR on each CI Job it would make the processus more fluid.
1 vote -
Branch Pattern Matching
I want to use branch pattern matching to map CI Jobs to specific types of branches in my repository.
main
uat
dev
feature/*
release/*
hotfix/*
chore/*Each of these branch types can have different CI Jobs associated with them. Or in the case of a chore/*, maybe I want those branches to Skip CI Validation because it is an ops branch that doesn't contain any Salesforce components.
1 vote -
Sandbox Deployment With 0 Components
Running a deployment into a Sandbox or Prod that has 0 components is a waste of time and resources.
If a deployment has 0 components in it, either
1. There's a problem because I was expecting greater than zero (so throw an error), or...
2. I want to run tests, and theres a different command for that (I shouldn't be executing a deployment just to run tests).1 vote -
Automate creation of a release, which includes several stories
Within pipelines, provide the ability to validate multiple Pull Requests (PRs) in one shot (i.e. release), so that this release could be deployed to production, for example, using Salesforce's Quick Deploy feature. This would be very handy when getting ready for a production release and I need to validate my release the day before. Thus, on the day of the release, I would simply Quick Deploy it.
2 votes -
Approve Pull Requests from Gearset
Currently you have to navigate from Gearset to Github using the link from the Pull Request to approve a Pull Request. While functional, this requires going to an external system for an important Git functionality. This also creates a bit more complexity for non-technical users. If we could approve PRs directly from Gearset, that would be awesome!
4 votes -
Schedule deployment option for validation only CI jobs
It could be good that time selection schedule option is available, makes release timetable easier to execute to target org.
Currently user can only execute the pre validated package immediately.
2 votes -
Allow Quick Deploy when merging multiple PRs using Pipelines
currently when merging multiple prs using pipelines the merged package validates and then the prs are merged, the resulting deployment then revalidates even though quick deploy is an option, can we use quick deploy when available like was enabled in the ci jobs?
this would save time by avoiding double validation and make the feature more usefull.
1 vote -
Copy reviewers to the cloned promotion branch PR in Pipelines (Bitbucket)
When Pipelines creates a promotion branch and copies a PR that was opened in Bitbucket, it does not copy the reviewers. This means reviewers have no way in the Bitbucket UI to filter for PRs that they're assigned to review.
Further, since all the cloned PRs are authored by the Pipeline owner, the lack of reviewers on top of that makes it quite difficult to visually differentiate between the list of open PRs, especially if you're both someone who creates & reviews PRs.
1 vote -
Pipeline automatic back promote
When using pipelines, it would be helpful to have the option to automatically back promote changes through the pipeline. For example, we currently have a CI job that pushes specific changes that admins are allowed to make directly in production into our master branch. We then have a Github Action that automatically merges commits to our master branch to the other branches in the pipeline, so that everything is synced. However, in order to turn on pipeline, we have to turn off our automated merge action, because pipeline creates a bunch of PRs when the automation runs. This forces someone…
5 votes -
Customize CI job commit message
When a CI job pushes changes to source control, it always uses the message "CI deployment from job <CI job name>". It would be very helpful to be able to customize this message.
5 votes -
Include Deployment Name on Continuous integration dashboard
On the Continuous integration dashboard, specifically in the Validation only CI jobs section, there is no way to associate a validation job with the deployment dashboard in Salesforce. We have a validation only job set up to run tests on PRs when they're created. If we get a handful of them all at once, there is a long list of validation jobs running, but we can't tell which one is the one that's actively running. There is no link between the job in gearset and the job in salesforce.
3 votes -
to let us configure the default metadata filter by deployment pipeline configuration
Can we please have a possibility to configure the "standard" metadata filter by each deployment pipeline project?
I think it is currently preselected by the last used metadata filter from the standard comparison.
As we usually have a specific metadata filter configured by deployment pipeline project, it would be great that we can configure each project with a default one..
Thank you!
2 votes
- Don't see your idea?