Justin Lyon
My feedback
19 results found
-
2 votes
-
1 vote
-
2 votes
An error occurred while saving the comment -
13 votes
-
10 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
-
22 votes
-
3 votes
An error occurred while saving the comment Gearset has already done the hard work of identifying that there are 0 component changes to be deployed. So under this scenario it should just NOT deploy into the target if that target is a sandbox or prod.
This happens most commonly when I am making updates to keep the repository in sync with the sandboxes, but the sandboxes already have the changes. Or if I'm making maintenance updates on our git repo that have no Salesforce components in them.
-
1 vote
-
3 votes
-
18 votes
An error occurred while saving the comment I'm shamelessly going to link to another user voice request on scripting that I think should be at the top of the list for anything pre/post scripting related.
I can appreciate the value this request is looking for, but I think we'll see a lot more value if this second, lower voted request get's traction.
-
5 votes
An error occurred while saving the comment Not only would I like to see bash scripting, but also extend this to allow us to run npm scripts out of the package.json.
An error occurred while saving the comment Adding pre and post deployment scripting that can also selectively execute by environment or by sandbox/vcs target types would be an awesome super power.
This would allow teams to craft their own scripts that pre/post deactivate/activate validation rules/triggers/custom metadata, or run linting on pre commit. Or Delete Old Flow Versions and Flow Interviews in post deploy. It would be huge.
-
2 votes
An error occurred while saving the comment I think this is a challenge for Gearset Releases because this happened despite following the pipeline process using the Expanded Branch Model.
1. Create Feature Branch
2. Compare and Commit
3. Create PR against UAT
4. Promote to UAT
5. Add to Release-- UAT Feedback captured from business --
6. Push change to Feature Branch
7. Create PR against UAT
8. Promote to UAT-- Gearset syncs gs-pipeline/feature_-_uat to _-_main
-- Gearset syncs gs-pipeline/feature_-_main to gs-release/ branchIt was UAT feedback changes that occurred on steps 6, 7, & 8 that ended up getting rejected and spun out again as new PRs against PROD.
-
10 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
-
1 vote
-
1 vote
-
5 votes
An error occurred while saving the comment +1 for branch pattern matching, this would be on par with our peers outside the salesforce platform using established tools like Azure DevOps, GitHub Actions, Jenkins, BitBucket Pipelines, GCP
-
15 votes
An error occurred while saving the comment This would also be an important feature for those of us that want to break up the happy soup into various packages. I might not want to check in a whole object for one of my packages, but there would certainly be a collection of custom fields that I want to check-in.
-
3 votes
-
2 votes
This would be huge to have this option.
This aligns with the way Salesforce treats a permission set xml as a single unit. And this is the whole reason why permission sets are preferred now over profiles, because profiles came apart into so many pieces and you had to combine so many metadata types to retrieve (and then deploy) profile changes.
Additionally my end users will commonly use the "Select All" checkbox in Salesforce to add fls to every permission set in the SF provided "short list". When this happens, the only way to fix it is to back out the fls one at a time on the extra permission sets in the sandbox because Gearset currently aggregates all perm set changes by custom field permission - I can't select which permission sets I want to include in my changes.