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.
187 results found
-
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…
1 vote -
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 -
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.
1 vote -
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 -
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 -
On Create Pull Request, auto populate details with commit messages
Similar to the way Bitbucket and GitHub work, it would be nice if the PR description was autopopulated from the commit messages (1 per line)
3 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 -
Revert with one click all changes from this PR
Please allow reverting PR from lower environments. In mine example, we had a feature that went through develop and uat and was waiting in the pipeline to be added to release but the business changed its mind and canceled this whole feature.
Please add an option that with one click we can revert PR and changes from lower environments.
Image:
https://www.dropbox.com/s/ohvymcs16p9n5ge/2022-06-30_14h10_44.png?dl=02 votes -
Include Deployment Name on Continuous integration dashboard
On the Continuous integration dashboard, specifically in the Validation only CI jobs section, there is no way to associate a validation job with the deployment dashboard in Salesforce. We have a validation only job set up to run tests on PRs when they're created. If we get a handful of them all at once, there is a long list of validation jobs running, but we can't tell which one is the one that's actively running. There is no link between the job in gearset and the job in salesforce.
3 votes -
to let us configure the default metadata filter by deployment pipeline configuration
Can we please have a possibility to configure the "standard" metadata filter by each deployment pipeline project?
I think it is currently preselected by the last used metadata filter from the standard comparison.
As we usually have a specific metadata filter configured by deployment pipeline project, it would be great that we can configure each project with a default one..
Thank you!
2 votes -
allow field level granularity in CI Jobs
Would like the possibly to set up a CI job that only syncs a sub-set of fields on a custom object. For example, we have an org to org sync where we want to update picklist fields but not autonumber fields. Currently we are running this job manually twice a day.
1 vote -
Possibility to validate a feature branch as a whole without having to select the Metadata type
It looks like the current validation jobs setup in Gearset needs the Metadata Type to be explicitly selected to perform the validation. This should ideally be optional and there should be a capability to just validate everything that is there in the feature branch against the target org. It's really annoying for us that we have to select the Metadata Types to be validated.
2 votes
- Don't see your idea?