Eric Kintzer
My feedback
60 results found
-
2 votes
An error occurred while saving the comment -
2 votes
-
3 votes
-
1 vote
-
3 votes
-
6 votes
-
4 votes
An error occurred while saving the comment if targets were scratch orgs, then presumably would run in parallel?
-
4 votes
An error occurred while saving the comment yep -- 100% agree
-
10 votes
An error occurred while saving the comment yes, what happened to this feature? it was so convenient
-
1 vote
-
1 vote
-
7 votes
-
2 votes
-
11 votes
An error occurred while saving the comment A more general solution would be to deploy from the data directory SObject Trees (json) that prepopulate the Scratch Org after the metadata has been deployed
-
2 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
-
3 votes
An error occurred while saving the comment This makes total sense and should go from the data directory in source control that includes SObject trees in JSON so they can be shared between Gearset, CLI, and Workbench
-
3 votes
An error occurred while saving the comment also, include namespace, if any
-
1 vote
-
1 vote
An error occurred while saving the comment if tooling api is used to run tests, wouldn't they run by definition with parallel testing enabled?
-
2 votes
An error occurred while saving the comment this looks like it would be really useful for consultants managing multiple clients
A solution would be to provide two dynamic params in the outgoing webhook JSON payload:
username (of the newly-created scratch org)
JWT (to the dev hub)
see http://www.wadewegner.com/2018/01/jwt-oauth-with-scratch-orgs/
this allows remote machines to login to the scratch org with only a username
see also: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm?search_text=sfdcloginURL#sfdx_dev_auth_jwt_flow