-
-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure MustPassRepeatedly at suite level #1265
Comments
hey - you can use |
@onsi Thanks for fast answer. Sadly we aren't using the CLI, I forgot to mention that! We'd like to set |
That isn’t supported yet (it’s just not implemented). i can imagine simply passing the decorator into Can you share why you aren't using the CLI? It’s required for running specs in parallel and I’d love to learn what issues you’ve bumped into. |
I've made this exactly the same way as how FlakyAttempts are handled a suite level and it works using my fork, I'll open a PR so we can discuss about the required tests I guess. Regarding our workflow, we compile the test binary and then spread it across N machines, each of them is calling the binary with different set of flags. These machines don't have Go or anything else installed. |
thanks for the PR! i’ll take a look as soon as i can.
that’s great! you can also compile and distribute the ginkgo binary and then run |
Works fine so I'll close! On a side note, any idea how we could get the timing of all these N executions for each tests during reporting step ( |
hey @maxcleme - the individual times aren't stored by Ginkgo but you can use Report Entries do something like this at the top level (e.g. right after the var _ = BeforeEach(func() {
t := time.Now()
DeferCleanup(func() {
AddReportEntry(fmt.Sprintf("Run %d", CurrentSpecReport().NumAttempts, time.Since(t))
})
}) If you share more about how you post-process the specs to generate reports I can offer some examples for how to then use these report entries. But, it's basically just data and data transformation at that point. |
Thanks for the answer, to be fair that's what I kind had before using Regarding context, we are reporting test suites in two formats, ideally we'd like:
|
hey @maxcleme - ah, understood. yes parsing the also makes sense about JUnit for UI - so many tools are built on top of JUnit's report format which is a bit of a shame since the format is quite anemic and not super well defined. One idea for you: you could take over generating the JUnit report yourself. You can mutate the |
Right, Thanks for those pointers! ❤️ |
wonderful - glad to be helpful and thanks again for the PR! |
We are looking at a way of configuring
MustPassRepeatedly
programatically at suite level before starting it, however it is not possible at the moment.Ideally, something similar to
FlakeAttempts
, where it can be set at node level using the decorator but also at suite level .Any insight on how we could perform this? Is there any reason why it is not present at suite level?
The text was updated successfully, but these errors were encountered: