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.
189 results found
-
Provide an API for querying deployment info
Please provide an API for querying deployment info such as friendly names, components, deployment notes, etc...
10 votes -
Option to create a CI job only for back propagation
We created some CI jobs for back propagation of changes from Production to other downstream branches and orgs. But these CI jobs also pick up pull requests(from a different pipeline) for forward propagation.
So, basically there is no way currently to create a CI job just for back propagation. It will be good to have a toggle in the CI job to mark it for forward or backward propagation9 votes -
Ability to automate deployment to a particular environment without manually promoting changes
When there are multiple Salesforce environments in the deployment pipeline, like Integration, Qa, Stage and Production, we would like to have ability to automate deployments to a specific environment, without having to select PR and promote changes manually. Most of the times SIT/Integration environment will be used for Developers to be able to perform integration testing, where we do not want someone like a Lead to review and promote PR manually. It will be beneficial to deploy the changes automatically, as soon as someone creates the PR to the Integration environment.
9 votes -
Ability to remove PR's from a created release
WHen working with pipelines, when we create a release and we merge PR's to the release so we can then deploy later, it would be nice if we have the option to remove them in case someone change their mind instead of cancell release and srtart over
7 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!
7 votes -
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:…
7 votes -
Better error reporting when CI jobs fail.
Better error reporting when CI jobs fail. Many times I open a failed job and there are no errors reported.
7 votes -
Provide a way to init a sandbox
It would be nice if there was a quick way of init'ing a new sandbox that matches either what was in source control or an existing sandbox.
Currently, I need to run a comparison between the existing source and the new sandbox and then I can try the deploy, but it would be nice if the compare step was not needed and I could simply say 'overwrite what is in the sandbox with what is in the specified source'
7 votes -
Automate Jira Status when a Pull Request is created in Pipelines
Presently, the capability to automatically update the Jira Status of a ticket is limited to transitions occurring between different environments in Pipelines. Enhancing this functionality to include automated updates triggered by the creation of a Pull Request would prove beneficial, eliminating the need for manual intervention when transitioning to stages such as "Code Review."
6 votes -
Invoke Run Anonymous Apex against target in CI Job
Team,
Can you please add Run Anonymous Apex option in a CI Job ?Step#1
In this scenario from Developer's end they should add pre scripts in a.txt file and add post scripts in b.txt file in their Source ControlStep#2
How it should work
- It should allow the CI job to run Pre and Post Deployment scripts
- Pre Deployment scripts should be picked up from Source control a.txt file and Post
Deployment scripts should be picked up from Source control b.txt file
- Post commit the diff of commit should identify what are pre and post scripts…6 votes -
Share edit access to a CI job with another user
Currently, only the owner of a CI job is able to edit it. This is a risk, as the owner is not always available to troubleshoot CI issues. It would be helpful to be able to delegate edit access to other team members so that pipelines can be managed collaboratively.
6 votes -
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.
6 votes -
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…
6 votes -
Add ability to clone deployment CI job to validation-only CI job
This would save us time duplicating regex statements for the new job
6 votes -
Allow CI jobs to validate PRs of a branch into Separate Scratch Orgs
Currently CI jobs can only validate PRs into a regular org. So if you have multiple PRs raised to that branch then you have to wait as they each run one after the other. If we could validate into separate Scratch Orgs instead then all the PR validations could run in parallel and it would speed up validation
6 votes -
Allow us to personalize the report generated at the end of the deployment
I want to send the automatic report generated at the end of the deployment to my client. However, I want to personalize it with the logo of my company or add additional text.
6 votes -
Allowing data deployments in CI jobs
Allowing data deployments in CI jobs. So that configurations in third party apps and B2B Commerce can be deployed as part of CI.
6 votes -
Auto merge of PRs
Once the validation process is successfully completed for the respective PR, it would be very helpful to have an option for automatic merge and deployment. This would streamline the release process and reduce manual steps.
Additionally, it would be great if we could have control at the org level to enable or disable auto merge functionality. This way, teams can decide whether they want to use auto merge based on their workflow preferences or organizational policies.
Thank you for considering these enhancements!
5 votes -
Save Problem Analyzer Changes to Deployment Set
When using the Problem Analyzer to identify and fix issues within deployment sets, it's common to add or remove items to address specific problems. Currently, these changes are not automatically saved, which can lead to recurring issues in subsequent analyses.
Suggested Enhancement:
Introduce an option that allows users to save their modifications directly to the existing deployment set or create a copy of the set with these changes. This feature would streamline the problem-solving process and ensure that resolved issues do not reappear in future analyses.Benefits:
Efficiency: Reduce the time spent on re-analyzing and re-fixing recurring issues.
Consistency: Ensure…5 votes -
Add pipeline support for CPQ
CPQ deploys to and from Github/Salesforce so it should be a relatively simple issue to include this in the pipeline deployments. You could add a checkbox or just warning to ensure that triggers are manually disabled when that is needed.
5 votes
- Don't see your idea?