Aidan Harding
My feedback
30 results found
-
2 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment -
2 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →
-
16 votes5 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 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.
-
1 vote
-
22 votes2 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →
-
2 votes0 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →
-
37 votes10 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →
-
19 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →
-
24 votes4 comments · Help us improve Gearset » Deployment automation · Flag idea as inappropriate… · Admin →
-
101 votes19 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment 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?"
-
1 vote0 comments · Help us improve Gearset » Monitoring and reporting · Flag idea as inappropriate… · Admin →
-
2 votes
-
1 vote0 comments · Help us improve Gearset » Monitoring and reporting · Flag idea as inappropriate… · Admin →
-
4 votes
An error occurred while saving the comment 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.
-
1 vote0 comments · Help us improve Gearset » Team and account management · Flag idea as inappropriate… · Admin →
-
12 votes
An error occurred while saving the comment 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.
-
15 votes
-
1 vote
-
9 votes
-
14 votes
I just came across another reason to do this... If there's a structural problem with the metadata (in my case, I'd mistakenly created a VF component in the pages directory), Gearset fails the validation before it's even told GitHub that the check is running. So, from GitHub, there's no sign that the check has failed.