Is there a way to populate dynamic data in the Tree Construction Phase? about ginkgo HOT 2 CLOSED

Do you know len(clientSecrets) in advance? If so then you can construct the table passing in a counter for each entry that represents the index into clientSecrets which you construct dynamically in SynchronizedBeforeSuites. If you don't know len(clientSecrets) ahead of time then you won't be able to do this. Ginkgo doesn't support dynamically adding specs after tree generation time. At that point your options are:

• fetch the client secrets in an init (though now every Ginkgo parallel process will fetch the secrets) and use that to construct the tree in the init.
• overprovision the number of tests (e.g. if len(clientSecrets) < 100 you could just have a hundred entries and simply skip the ones that don't apply)
• put it all in a single It.

Thanks for the prompt reply Onsi :)

Unfortunately we don't know the len of clientSecrets in advance. I think that I'll go down the init road as it feels like a fair trade off in order to ensure that we keep the use of running things in parallel, plus I don't think that having it all in a single It will ever get past a PR review here :)

from ginkgo.

Do you know len(clientSecrets) in advance? If so then you can construct the table passing in a counter for each entry that represents the index into clientSecrets which you construct dynamically in SynchronizedBeforeSuites. If you don't know len(clientSecrets) ahead of time then you won't be able to do this. Ginkgo doesn't support dynamically adding specs after tree generation time. At that point your options are:

• fetch the client secrets in an init (though now every Ginkgo parallel process will fetch the secrets) and use that to construct the tree in the init.
• overprovision the number of tests (e.g. if len(clientSecrets) < 100 you could just have a hundred entries and simply skip the ones that don't apply)
• put it all in a single It.

from ginkgo.