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.
158 results found
-
Allow a PR template from GitHub to pre-populate the PR description
There is a feature in GitHub to auto-populate the PR description (forcing, for example, a checklist if using the web UI). If Gearset could read that template and pre-populate the PR description so users have to put in specific comments (such as manual steps to be done after deployment) and if that description were exposed in GitHub, then it would be more seamless and the deployment history would enable an admin to work through each manual step without looking in closed PRs in Gearset.
2 votes -
Allow different source control users per CI job
At the moment, my GitHub user is defined at an account level. So that user is the one for all CI jobs.
I may want to have a different GitHub user for each of the projects that I run through Gearset. For example, if we are a consultancy that generally use our own stack, but have to use a GitHub user belonging to a customer on some occasions.
Or (as I do now) I may want to switch my GitHub user from one to another. Today, switching that user will disable ALL OF THE CI JOBS. And I will have…
1 vote -
When merging a Pull Request that is linked to an Azure DevOps work item, indicate the user who performed the merge
Currently, when a PR is merged into an Org (and the PR is linked to an Azure DevOps item), a discussion comment is added to the DevOps item documenting the merge. However, there is no indication in the comment to document the user who performed the merge. The Author of the comment appears to be the owner of the pipeline, not the user who performed the merge. My suggestion is to either make the author of the comment the person who performed the merge, OR in the content of the comments, add a line to indicate "Merged By: [Name of…
1 vote -
Show the status of a CI deployment on the pull request
We use merge-based deployments, so whenever a Github pull request gets merged to /main, a CI deployment job fires that deploys the content of the PR to Production.
The issue is that at the moment all Merged PRs look the same, whether the deployment actually succeeded, or failed. There's no way to tell, or even to follow progress, unless we ask people to open the Gearset job and then look at the deployments for that job etc. which is quite a bit of a faff.
Validation jobs do display on the PR whether they passed or failed, the same feature…
1 vote -
Manual button to refresh repository data
Multiple times in the past, my team has added new files to our git repository and Gearset dose not pick them up as existing in the repository when we do a comparison.
Select your git repo/branch as the source, select the sandbox you want as a destination, the comparison page says "fetching repositories", but it doesn't seem to actually pull the updated data from the branches. My comparison builds fail because the new file isn't included in the comparison. Gearset usually ends up picking them up in ~12 hours but it's a huge workflow blocker when a tool doesn't have…1 vote -
Allow CI jobs to use the running users GitHub connection
At the moment CI jobs within the Pipeline use the CI owner's GitHub account for new branches and pull requests etc which is stopping the code reviewers process within GitHub from working currently.
Can we allow the integration within Pipelines to run on the promoting user's connection (i.e. so requests are shown with the running user and not CI Owner within GitHub) or allow a generic user to be set up instead to untie deployments from the CI owner GitHub connection within Gearset.
3 votes -
Read the PR title and prevent making feature branches for specific PRs against pipeline branches
If Dependabot opens a PR to update, say, a dev-dependency, then Gearset intercepts that and does its thing, including back-propagating that PR. But if I'm making branches from main, all I need is that PR to be merged to main, and it will come along the pipeline with other PRs opened against the beginning of my pipeline.
If you read [skip ci] in the PR title, or perhaps if the PR starts with a specific prefix (like ci or build, which would follow conventional commits) then just let that PR go against main and ignore it.
I have workflow to…
1 vote -
In Azure Repositories, maintain owner when changing PR to gs-pipelines
When dealing with Azure Repository, the owner of the gs-pipeline PR is always the user used for authentication. Any way to include the original owner would be helpful since the messaging is lost this way
6 votes -
Jira comment only for production releases
We would like to have the option to choose which deployments create Jira comments. As business users often watch our Jira tickets, we would prefer only posting comments when we actually "release" (deploy to our production org) and skip comments for releases on sandbox environments.
15 votes -
Add ability to run sfdx force source status command for metadata deployment
It would be great if, when comparing an org to a repository, we could run the status command (sfdx force:source:status) to see the difference between a Salesforce org and the repository.
This command provides a list of files that changed to the user instead of performing a full (and tedious) comparison between the source and the target.
Having a list of changed files would make it easier for a user to see what change they made in an org, make it easier for them to not miss a file and would make comparison so much faster (since you would be…
1 vote -
Let the user post Jira comments as internal or customer-facing from deploys
When deploying from sandbox to sandbox, we'd like the comments to post on the tagged jira issues, but would like to keep those comments internal instead of updating our clients. It would be good to have a security selection option when posting comments from gearset to jira.
3 votes -
Have the Jira ticket which was selected at the point of the commit stay with the PR in Pipelines
At the moment when you select a Jira ticket at the point of commiting to a branch, you are able to track that actionback into Jira.
However when a PR is opened from that feature branch to the next environment branch (in the Pipelines UI specifically) the Jira ticket association is lost, and has to be reattached manually.
Workaround:
- Put the ticket ID in the branch name, i.e. name your branch "feature/AL-99- new-flow"
- Use the drop down menu provided in the Pipelines UI to re select the Jira ticket
- Open the PR from the Commit successful screen and tick the…
2 votes -
Notify GitHub that checks are running sooner
When a PR in GitHub is being validated, Gearset doesn't let GitHub know that the check is happening until after it has run the comparison between GitHub and the target org. Then the check is pending while the validation runs in Salesforce.
This means that there is a delay between when you create a PR and Gearset's check appearing as pending in the PR. At that moment, it looks like there are no more checks to run in GitHub so you can go ahead and merge. But, you really should wait until Gearset has compared and validated the changes.
It…
3 votes -
Associated Work Items through Commit message
As a Developer, I want to use a unique ID from the work item I am working on
when I make a GearSet commit
So the work item I am working with (like Jira) can have a comment stating it was deployed
and I don't have to manually go to a separate process to update the ticket.Say my work items are in jira and I am working user story 100.
There is a Jira ID that is unique to that work item.When I specify a commit
instead of going through the separate process to find the work item…4 votes -
Allow squash merge for Github PR
We have our GitHub PR settings set to only allow Squash and Merge for PRs because we want a clean history on the long-lived branches. It seems Gearset doesn't support this, when I attempt to promote it issues an error. This should be configurable or should detect this automatically from the settings.
2 votes -
Have the Jira ticket which was selected at the point of the commit stay with the PR in Pipelines
At the moment when you select a Jira ticket at the point of commiting to a branch, you are able to track that actionback into Jira.
However when a PR is opened from that feature branch to the next environment branch (in the Pipelines UI specifically) the Jira ticket association is lost, and has to be reattached manually.
Workarounds:
1. Manually add the ticket ID to the PR description, which will reassociate it
2. Use the drop down menu provided in the Pipelines UI to re select the Jira ticket
3. Open the PR from the Commit successful screen…2 votes -
Disable Jira notifications for individual CI Jobs
We like that the Jira integration posts changes to the associated Jira ticket during a deployment, but we only want notifications for specific CI Jobs. For example we want our staging and prod deployments to post a notification in our Jira ticket, but not for other jobs such as back-deployments. Each post potentially emails Jira users and we want to limit these notifications. Currently the only work around is to remove the Jira ticket association from the PR in Gearset before promoting it, and this gets tedious if you have a lot of development orgs.
2 votes -
Include Apex classes regardless of folder
In GitHub, Apex classes don't always have to be in a folder called "classes " to work with them. Some people using SFDX put test classes in their own folder (sometimes called "tests". Even Apex classes within the "classes" folder can be sub-grouped into folders. (Example at https://github.com/trailheadapps/apex-recipes/tree/main/force-app/main/default/classes)
I'd like Gearset to scan the entire repository and to group metadata by its actual type, not by the folder it is in.
I'm not talking about the sfdx-project.json saying where the metadata is located. This is within each of those locations, it should find all Apex (for example). The Apex…1 vote -
Delete GitHub webhook when the CI job is deleted
When we create a CI job where the source is GitHub, Gearset can automatically create a webhook for us in GitHub.
Would it be possible to delete that webhook in GitHub when we delete the CI job from Gearset? I've got some GitHub repos with failing webhooks due to CI jobs I once created. Obviously, I can tidy up manually from GitHub, but it would be nice to have the option of Gearset doing it for me. The URL seems to be unique to the CI job, so I can't see it having any negative consequences.
3 votes -
Allow for Object Deployments without subcomponents to git
When deploying an object to git currently there is no support to ONLY deploy the object metadata.
We have a large managed package that your code requires the .object file for an object in that managed package to exist for me to deploy fields or other customizations for said object git -> org. When I deploy org -> git to get the .object file into my repo it also grabs all the fields on the managed package object which I don't want/need.
I don't want the fields and I need to specifically get it from the target org because if…4 votes
- Don't see your idea?