Aidan Harding
My feedback
-
15 votes4 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Aidan Harding
supported this idea
·
-
18 votesAidan Harding
supported this idea
·
-
1 vote0 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →Aidan Harding
shared this idea
·
-
13 votes2 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
1 vote0 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →Aidan Harding
shared this idea
·
-
32 votes9 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
14 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
26 votes7 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
20 votes4 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
83 votes18 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Aidan Harding
commented
Please, please, please!
I'm comparing around 4k components, selecting about 200, and one of them is giving me a different error on each deployment.
So I'm having to wait 10 minutes for Gearset to recognise the fact that I've removed one element from a LIghtning page, and then go round again.
To quote from our customer when they saw the time it took to deploy for them "Is Gearset the right tool to use for this?"
Aidan Harding
supported this idea
·
-
1 vote0 comments · Help us improve Gearset » Monitoring and reporting · Flag idea as inappropriate… · Admin →Aidan Harding
shared this idea
·
-
105 votesStarted · 23 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Aidan Harding
supported this idea
·
-
1 voteAidan Harding
shared this idea
·
-
1 vote0 comments · Help us improve Gearset » Monitoring and reporting · Flag idea as inappropriate… · Admin →Aidan Harding
shared this idea
·
-
3 votes
An error occurred while saving the comment Aidan Harding
commented
This would also be useful for org-monitoring.
My no-namespace unlocked packages are part of the code I want to monitor and run PMD on, but the only way I can currently achieve that is to include all packages in the metadata filter. This means I have a baseline amount of static analysis issues which are stuck inside managed packages and so it's harder to notice problems in code that we actually control.
Aidan Harding
supported this idea
·
-
1 vote0 comments · Help us improve Gearset » Team and account management · Flag idea as inappropriate… · Admin →Aidan Harding
shared this idea
·
-
8 votes
An error occurred while saving the comment Aidan Harding
commented
We're like the option to disable triggers for the data deployment, then restore them afterwards, too.
Obviously, we never write non-bulkified triggers, but sometimes inherit systems that do. And some trigger may have side-effect (email, callouts) that you don't want to happen when just migrating test data.
The selective approach would be best for this as some triggers may be necessary to keep data integrity, even when inserting test data.
Aidan Harding
supported this idea
·
-
12 votesAidan Harding
supported this idea
·
-
1 voteAidan Harding
shared this idea
·
-
9 votesAidan Harding
supported this idea
·
We frequently have to add fields to managed objects. Not being able to deploy those fields via CI is a great pain and another hole in the idea that git is the source of truth.