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.
150 results found
-
Trigger Gitlab Pipeline Faster
When opening a MR in Gitlab, the Gearset pipeline queues the Validation very quickly. However, in Gitlab, there is no pending Pipeline until Salesforce starts the validation. Sometimes this can be a lengthy period of time with no visibility inside of Gitlab.
Would be nice to trigger that immediately so approvers can see that it is queued, not just no pipeline job has been executed yet.
3 votes -
CI job merger conflicts
When resolving CI job merge conflicts, a user has two windows to accept changes from one side of the window. Can we have an option to accept specific components changes from one side and certain changes from the other side.
4 votes -
Microsoft Teams CI Deployment Job Notifications - Add Source Commit
There should be parity with the content included with a Teams web hook notification. With Slack, the Source Commit attribute is included.
With Teams, it's omitted. Please add so this data point is available with Teams. Current output illustration.
Slack
Gearset Continuous Integration
A continuous integration run succeeded for SIT Deployment / Validation job for PR #97. The job was a validation. No changes were detected for deployment.
Source commit
5ccc5b72Teams
A continuous integration run succeeded for SIT Deployment / Validation job for PR #97. The job was a validation. No changes were detected for deployment.
1 vote -
Enforce Promotion Approval Rules
The current UI shows a green checkbox and allows you to attempt to promote changes between environments even if the merge request is unable to be approved. Looks like it in Gitlab there is an 'approved' attribute that may be able to be used.
Alternatively, can have some basic rules but would like it called out its not ready to Promote in the Gearset UI.
2 votes -
Pipeline PR User interface Details
Currently we can see Jira ticket status when we look at PRs in the pipeline UI it would be phenomenal if we could include additional Jira fields to be seen from Pipeline UI such as Summary or fixversion
1 vote -
Improve Deployment Information in Notifications
I've tried both Email and Teams integrations and the actual information in the message (or attached PDF for Email) is lacking, with only great piece being the branch name.
An option to get advanced details that could provide some of the below (but not limited to):
- Actual Links - Atleast with Gitlab Self-Managed, we just get a text-based message referencing a merge request.
- Commits / Original MR - For those deployed via a Pipeline, getting the original MR (our pipeline is dev org > QA > UAT > Staging > Production, with the Dev Org > QA being…1 vote -
Show all Github requirements to merge in the Gearset pull request view.
We have required approvals enabled on PRs in Github. Currently when viewing a Pull Request in the Gearset Pipelines view, it does not show that a PR is blocked from being merged because at least one code review approval is needed in Github. This leads to accidentally attempting to "promote" in Gearset and then the Pull Request merge fails. We would like to see these (and any other Github requirements) showing up in Gearset so we are informed which PRs are approved and ready to promote.
10 votes -
Integrate with Agile Accelerator instead of just Jira
Integrate with Agile Accelerator instead of just Jira.
It would be great if Gearset (and ideally the Pipelines-feature) could integrate with Agile Accelerator.Since we're a Salesforce-partner we want to use as many Salesforce-native solutions. That's why we've been happily using Agile Accelerator for many years.
It would be great if Gearset can also integrate with Agile Accelerator instead of just Jira.
Right now the Gearset Pipelines feature isn't useful to us, because of this sole reason.Thanks for considering this!
28 votes -
Support Gitlab Application Tokens for CI Jobs
Gearset uses User-level Application Tokens which is great for all user-initiated requests. However, things like automated commits, new branches, etc would be ideal if we could tie to Gearset. Gitlab supports granting out tokens at the Group or Repo-level where we could provide a better and more auditable tracking of Gearset automations
1 vote -
Automated Commit Message Identifiers
It would be great if automated commits/PRs/etc had a note that called out they were automated for audit purposes.
1 vote -
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 -
ClickUp integration would be awesome!
My company uses ClickUp to manage tickets, would be great if there was integration with Gearset as that would save me copy/pasting ticket references into the deployment descriptions.
3 votes -
Integrate with Linear
Linear is quickly becoming the new Jira for today's technology and engineering teams. It should be considered an important integration.
2 votes -
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 -
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.
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
- Don't see your idea?