Skip to content
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

Parallel tests and code coverage from multiples machines #107

Closed
arboleya opened this issue Oct 2, 2015 · 5 comments
Closed

Parallel tests and code coverage from multiples machines #107

arboleya opened this issue Oct 2, 2015 · 5 comments

Comments

@arboleya
Copy link

arboleya commented Oct 2, 2015

Hello @nickmerwin ,

I've just found this article in another thread.

However, besides setting the COVERALLS_PARALLEL=true env var, I didn't get what else I need to do.

Can you please give more detailed instructions or a working example?

I'm using TravisCI (for osx/linux) and AppVeyor (for windows).

Thanks in advance.

@nickmerwin
Copy link
Owner

Hi @arboleya unfortunately we're not able to merge coverage data across CI's yet (unless the job ids are the same). I can see how this could work -- cross-referencing the commit SHA as opposed to the build number from the CI. Supporting arbitrary number of CI's per build has quite a few UI implications, but is definitely doable.

I'm not sure how this will fit into our dev queue, but I'll keep you posted!

PS perhaps you could hack this by short circuiting the CI_BUILD_NUMBER and CI_JOB_ID to be the current git SHA in the build ENV, but then you'd need a way to handle multiple webhooks. If you know one of the CI's always takes the longest, you may be able to get away with having that one send the hook.

@arboleya
Copy link
Author

arboleya commented Oct 3, 2015

Oh I see, sad thing. But there's support for multiples builds from the same CI?

Because if yes, it'd be a matter of using the commit SHA as identifier instead of a build number or whatever you are using now. Am I being too simplistic?

@nickmerwin
Copy link
Owner

Yes, that's possible, but the other issues would be:

  • linking to the separate CI's from the build/job views
  • knowing when all have completed in order to send notifications / update PR status checks on GH

@arboleya
Copy link
Author

arboleya commented Oct 3, 2015

Linking to separate CI's shouldn't be hard, it's one pattern per service.

I wouldn't mind about know when it's finished, too complicated. Instead, I'd be always merging payloads that are sent, so you sent just one, you got coverage for one. If another one comes in, merge data, display a new CI button, e display the percentage of it all.

Well, just ideas.. as it is absolutely out of my control :)

I'm thinking about doing a middleware where all my tests posts its coverage to, then I get all merged and submit all at once as a single report. Not ideal, will take some time, but it's doable.

It's a feature I didn't find anywhere, not in coveralls, not in codeclimate etc.

Could be a differential too.

@terinjokes
Copy link

@nickmerwin I'd also be interested in being able to support different CI vendors, since i also use travis + appveyor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants