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.
165 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...
9 votes -
Create releases in Pipelines not at final stage
Right now you can only create releases at the last environment in a Pipeline. We'd like to have 2 stages so we have a true dry-run of deployment. Our pipeline is
Dev > QA > UAT > Staging > ProductionCreation of the release branch before Staging would allow us to effectively cherry-pick what we want deployed into Staging as we get UAT approvals, do a test deployment where QA does a sanity/smoke test and have greater confidence when we get to our Production release.
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 -
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.
6 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
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 -
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 -
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.
6 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'
6 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 -
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 -
Allow the creation of CI Jobs against Salesforce orgs that we are delegated to, instead of needing to be owner.
We have 2 admins that we want to be able to create all of the CI and Pipeline Jobs, even if they don't have their own credentials in a particular Salesforce org. They have Deployment delegation, and can run compare and deploys, but not set up integration jobs.
This is then requiring us to either, provision extra licenses in each sandbox for our DevOps administrator, or have the developers create the CI jobs, which they are not comfortable with.
And, as we start the Pipeline Pilot, we would like to leverage all of the existing CI jobs, but, that is…5 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.
5 votes -
view deployed components live
Show live the components deployed during the running of a CI/CD Job.
Like:
deploying class abc.......
deploying class xyz.......
deploying lightning Component abc.......5 votes -
allow a method to set up default branches.
I frequently deploy from our on premises GitLab repo. It would be great to have the ability to set the default branch it goes to. It would be one less click for repetitive steps
5 votes
- Don't see your idea?