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.
151 results found
-
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…5 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.
4 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.
3 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 -
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…
2 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 -
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…
3 votes -
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.
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 -
Granular Permissions
Most of our users don't need to be doing any configuration outside of connecting their Dev Sandbox. Prefer to have more granular permissions to lock down features to smaller groups of users.
2 votes -
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.
1 vote -
retain validation history for CI jobs
When a pull request is created against a branch that triggers a CI job, a validation is run. Sometimes, this validation hits errors and adjustments need to be made to the metadata filter and/or problem analyzer template until the validation succeeds. However, once the PR is promoted and the CI job successfully fires, the validation history for that PR is no longer accessible. It would be useful to be able to retain that validation history, as it would help to do further investigation into the validation errors that were hit after the fact.
There is not always time during a…
2 votes -
Ability to rerun deployments
We had a deployment in a pipeline that included a change in a managed package. the MR to the environment branch has the permission set change (access to a managed package field), but the Pipeline did not deploy it. It would be great if there was a way to "re-run" an already promoted branch, as we can't use a MR at this point to trigger, since the repository already has the change.
1 vote -
Provide deployment history by Salesforce ID or My Domain
If we could have a way to quickly export all changes to specific environments regardless of user who created the connection, would be ideal.
Use case: Provide a Production OrgID and be able to export all changes across all connections and manual compare-and-deploy and pipeline deployments.
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).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.
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.
1 vote -
Run pull request validation against a different sandbox than the one linked to the target org
Hi team,
We have multiple developers creating PRs against a common development branch (let's call it simple, develop; developers are creating their feature branches from master, the Production configuration branch). Develop branch is linked to an integration environment (called INT). INT environment contains multiple stories which are not yet in Production (some of them might go in Production, some will not go).
I would like to get my PRs validated in a Production-copy environment (called BUILDCHK) just to get a real feedback on how "deployable" are my changes in Production, for whenever their time will come.
It would be great…
1 vote -
Add the checks on the PR for the deployment
Currently, gearset doesn't provide the checks on the PR for the deployment CI job. It would be nice to have the checks of the deployment status along with a link to the comparison on the PR, similar to how we can link out to the validation job
1 vote
- Don't see your idea?