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.
189 results found
-
Job Completion Percentage
I would like to see more details about the status of a deployment or validation job in the Pipeline. Right now it just says job is running. I would like to see a estimated percentage of component validated/deployed against the total. Also maybe a running time estimate.
2 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.
2 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 -
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 -
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 -
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 -
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 -
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 -
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 -
Clone Problem Analyzer Templates
With CI jobs, you may need to refine over time your Problem Analyzer templates
However, there is no clone button and you have to carefully set up the new template (as edit-in-place is not supported when the template is already assigned to a CI job - at least that is what the in-app guidance tells you)
So --
a) Allow Clone from page app.gearset.com/problem-analyzer-templates
b) Allow an easy way to assign the new template to all CI jobs without having to do each 1 x 12 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 -
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 -
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 -
Manually Delete Metadata after CI job runs
We don't want the CI job to delete metadata, so we've unchecked that box. However, when a CI job runs that would have deleted data, we'd like to be able to select from the job history, review what would have been deleted and elect to deploy the deletion manually post CI run. We can re-run the comparision from Compare and Deploy, but having this action tracked within the CI job history would be more convenient, and would allow the history for the target org to be contained in the same thread.
2 votes -
CI Deployment on a Schedule
We would love to schedule a deployment from GitHub source to a few sandboxes at the end of each 2-week sprint.
2 votes -
Granular "difference types to deploy" on a metadata level
In the CI job, we would like to have the ability to specify on a metadata level if we want to deploy new items, update items and delete items. There are examples of metadata where we always want to delete and others where we don't want to.
2 votes -
Add option to provide exact time in case automatic deployment
We need to set exact time for automatic deployment. We need this option for example for night releases for specific client. This is important for international clients that works in different time zones
2 votes -
Add the ability to order/chain overnight jobs
Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.
it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:
- Monitoring Snapshot
- CI run
- Unit testing
This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.
Ideally, we'd be able to do this without just specifying exact times to…
2 votes -
CI/CV job archiving
Create a mechanism by which CI and CV jobs can be archived, but not deleted. Sometimes there is a job that is not used, but the history needs to be kept for some period of time.
2 votes
- Don't see your idea?