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.
195 results found
-
Option to not run job periodically
In the "Run job" field allow an option to don't run job periodically at all. Sometimes we nedd a job to run only manually, when needed, and now I need to remember to disable it manually each time
1 vote -
More efficient spacing on Pipeline environments
We can only see 4 sandboxes at a time when fully zoomed out. We have 9 sandboxes. Since we aren't able to zoom out further or rearrange the sandboxes we are constantly dragging the screen to pan up and down, to see the state of the orgs.
There is so much whitespace in each node, any chance you could lessen the padding/spacing between the lines in each box/env/node, or between the nodes themselves? Maybe proportional to the max nodes in a single column?1 vote -
1 vote
-
1 vote
-
Give CI/CD Users the option to use a shared webhook or a new one in BitBucket
Gearset recently updated its automated webhook setup for new CI/CD jobs to use a shared webhook. For my team, we have configured each webhook for validation jobs to only run on PR creation/update and deployments to only run on branch pushes. By forcing the new jobs to a single shared job, it causes PR merges to trigger validations alongside the deployment (Which is time-consuming and needless).
Also, as my team has many legacy webhooks for our existing jobs, when we add a new job it seems Gearset randomly assigns it to an existing webhook. For our recent deployment-only job, it…
3 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 -
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 -
Schedule Release Validation
We've run into ROW LOCK issues in the past while running unit tests during validations in production which caused some issues with external Community Users, thus as a best-practice we try to run production validations after business hours.
I'd like to be able to schedule release validations from Gearset, or expose an endpoint that would allow me to trigger a CI validation for a release or PR.
1 vote -
Pipeline Sync Environment & Dev Environment
Currently we only have the ability to sync static pipeline environments. This is well and good but unfortunately syncing the Project branch can be time consuming and confusing Its not as simple as syncing the static environment.
I suggest when I sync the static environment , the sync action automatically opens a back propagation PR to the Dev environment its connected to. Also this sync action should close any pending open PRs against that dev environment that overlap with the sync PR.
3 votes -
Add Manage Custom Filters option when creating a CI job
When I use options Automation -> Continuous Integration -> Dev Sandbox -> Compare and commit for deployment, there is no option to create a custom filter.
Custom filters can only be created by using Metadata deployments -> Compare and deploy option.
Since the following tutorial https://docs.gearset.com/en/articles/6166062-promoting-your-first-features recommends to use Automation -> Continuous Integration for deployment, it would be nice if this way of deployment also had an option to create custom filter.1 vote -
Disable Pipeline Back-propagation for Static Environments
We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.
When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…
3 votes -
Add wildcard Test selection
When selecting tests to be run for validation or CI validation jobs, we should be able to select "Test classes" and provide more generic search names such as "Test.cls" or "classes/". This would allow dynamic updates to the selected tests based on available test in the deployment package.
1 vote -
Indicate from Gearset if a deployment is eligible to use Quick Deploy
I would like to be able to see from Gearset if a deployment is able to utilize Quick Deploy. This would be particularly useful for releases to production as we release after hours and our unit tests can take many hours to run. Knowing that Gearset will use Quick Deploy will increase our confidence with our release and reduce mental load knowing that the deployment will be much more likely to succeed.
2 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 -
Remove limitation of number of PRs to be added to a Release (Azure DevOps + Gearset)
Gearset automatically adds all PR details for a release in description box (Azure DevOps PR) which has max character limit of 4000 and only 16-18 PRs can be added to a release because of it. When we add one more PR after the limit is reached then the next PR does not get added to the Release and we need to create another release for them which is not correct approach as other releases may have some dependency on 1st and thing may fail in production. We need a way to disable adding description to Azure DevOps Release PR so…
2 votes -
Salesforce Data Processing Engine metadata deployment
Enable the Data processing engine component deployment via Gearset. The metadata name is"BatchCalcJobDefinition"
1 vote -
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.
3 votes -
Add option to "run tests if X is present" on CI jobs
At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.
At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally…
4 votes -
Need to be made aware and/or given the opportunity to view the totality of the changes prior to deployment
Heres what happened, we deployed the Metadata AND a ChatBot. As part of our deployment, we manually updated the metadatas to contain PROD relavent info (instead of ACC info that was pushed from ACC Branch)
I also discovered that there were duplicate utterances in the Chatbot which we had to remove via manual DML deletes to ensure that the Data Model was built properly.
Then, we wanted to deploy just a Field change, and did so by merging a PR containt just the Field Change into main in Azure. This, obviously, triggered a deployment and in that deployment, the metadata…
1 vote -
Better Automated Pipeline MRs
The MRs that get opened for pushing the same work through pipeline aren't very helpful. Would love to link back to the original MR which would have more of the "approvals". Right now we end up having to re-approve everything like its from scratch. Insight and auditability (maybe even bringing up who approved the original MR/etc would be great)
1 vote
- Don't see your idea?