Justin Lyon
My feedback
19 results found
-
13 votes7 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
An error occurred while saving the comment An error occurred while saving the comment I posted a related idea for this same issue as it presents during validation (and presumably deployment as well)
https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/46137910-local-metadata-ignored-if-name-collides-across-anAn error occurred while saving the comment SFDX CLI default behavior does not retrieve unlocked package components. If I retrieve wildcard on Lightning Web Components, I only get my local Lightning Web Components. Nothing from unlocked packages is retrieved.
Gearset must be doing something additional during comparison to retrieve unlocked package contents in addition to SF's default retrieve behavior. Because Gearset is now changing Salesforce's default retrieve behavior this must be an opt-in feature. Not everyone wants to retrieve the contents of unlocked packages to their repository.
Because this is NOT an opt-in feature, this creates new problems. There is currently a separate, but related, bug in the Gearset comparison behavior. During comparison, components of Namespaced Unlocked Packages are retrieved, and the Namespace is lost or dropped. When a component behind the namespace has the same name as a component outside of the namespace, the comparison combines the two components into a single file or folder. In the case of Lightning Web Components, two colliding components are two folders of various files; and when the bug occurs all the files between the two components are combined into a single LWC folder.
There are identified work arounds using regex and manually maintaining my Comparison Filters. This does not scale and requires too much effort from our team to maintain. Most interestingly, and somewhat frustratingly, the Gearset Comparison Filters' Advanced Settings properly identifies the namespaced unlocked package and lists the components using their namespace. Frustrating because apparently when the Comparison itself is executed that same namespace is forgotten.
Finally, I see this as two separate issues -
1. Gearset should not by default retrieve Namespaced Unlocked Package components. But should be an opt-in feature similar to managed packages.
2. Gearset cannot drop the namespace for Namespaced Unlocked Package components during comparison execution. -
1 vote
-
2 votes
An error occurred while saving the comment 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.
-
8 votes
-
10 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
-
15 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
-
17 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
-
1 vote
This should be available today. The lack of support for unlocked packages in Gearset is a serious consideration when deciding whether our team can take on new dependencies. I would like to add the helpful unofficial sf Flow Components utils for example, but it's just not worth the pain of maintaining the exclusions in the comparison filter.
As an example Unofficial SF's List Functions for Flow, which itself has two other dependencies as well.
https://unofficialsf.com/list-actions-for-flow/#installation