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.
194 results found
-
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…
2 votes -
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
2 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.
4 votes -
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 -
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…
2 votes -
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 -
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.
2 votes -
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…
3 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.
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!
7 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 -
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.
3 votes -
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.
3 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 -
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 -
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)
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…
7 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
- Don't see your idea?