Open rzetelskik opened 1 year ago
I am on board with propagating the args properly, the other part would need a link and/or more detailed description especially if we come to it after a while.
Each suite is compiled (https://github.com/onsi/ginkgo/blob/3e39231dee937854d166b210e0542798da58aa09/ginkgo/run/run_command.go#L110) before the parallel processes are run: https://github.com/onsi/ginkgo/blob/3e39231dee937854d166b210e0542798da58aa09/ginkgo/run/run_command.go#L153 and https://github.com/onsi/ginkgo/blob/3e39231dee937854d166b210e0542798da58aa09/ginkgo/internal/run.go#L31. The parallel processes are then started with a path to the compiled suite provided trough arguments: https://github.com/onsi/ginkgo/blob/3e39231dee937854d166b210e0542798da58aa09/ginkgo/internal/run.go#L43.
Of course it would first need assessing whether that would be worth the additional effort.
The Scylla Operator project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
/lifecycle stale
/remove-lifecycle stale /triage accepted
Currently our test runner passes raw command line arguments to the children processes, only modifying them accordingly. This has led to https://github.com/scylladb/scylla-operator/issues/1245. We should pass validated and completed arguments instead. Better yet, we could also do what Ginkgo CLI does, i.e. the parent process could compile the suite and pass a path to it to spawned processes.