Three.js: Threejsworker

Created on 28 Sep 2015 · 44Comments · Source: mrdoob/three.js

Threejsworker is a website built to enhance the development of Three.js. Right now, the only thing, it can do is get all pull requests, build them and show the examples. All within a minute of publishing the code on github. Which is something @WestLangley and @bhouston asked for.

It simplifies to check out a Pull request and it doesn't hide any file in the repository. It can be used to view the editor or anything in the repository of that Pull request.

Right now there are still some problems with it:

It is hard to navigate from a pull request and the website and back.
It doesn't generate any minified files(even three.min.js is a non-minified version).
If you want inactive Pullrequests to get shown, you either have to comment on that pull request or call
http://threejsworker.com/api/pullrequests/{{pullrequestID}}/ and give it a minute to process it.
It isn't very intuitive to get back from the examples to the index of pull requests.

It also brings other possibilities like:

A automatic Pull request to cleanup based on Mr.doob's Code Style™ (could be daily updated or something)
Comparing version of three.js examples in a single screen simply by selecting a different option.
Automatic testing of our growing unit tests.
and more of course

I just hope it is a welcome update. At the very least it is for me a useful tool to test big PRs in a simple way. Which is why I'm planning to open source the code later this week, so it doesn't get lost.

Source

gero3

Most helpful comment

I guess so... http://rawgit.com/ has been proving fairly useful lately though. I'm tempted of writing a little tool using github API + http://rawgit.com/. It won't do the compiling Threejsworker did, but it is super handy to try three.min.js from different commits and find when something broke.

mrdoob on 16 Dec 2016

👍2

All 44 comments

@gero3 you are amazing! Holycrap. If @mrdoob allows it you can actually integrate right into Github with status updates on each PR that the build is available. Such that you can report that the build of three.js and three.min.js failed via build.bat back to the PR: https://developer.github.com/v3/repos/statuses/

bhouston on 28 Sep 2015

The status can be that the build succeeded or failed and the target_url can link to the examples for the pull request.... :)

bhouston on 28 Sep 2015

You could also run the ThreeJS unit tests and only state that the build succeeded if those succeeded as well. And you can link to their output as well. We have this for our Clara.io unit tests via Jenkins' github integration.

bhouston on 28 Sep 2015

@gero3 you are amazing! Holycrap. If @mrdoob allows it you can actually integrate right into Github with status updates on each PR that the build is available. Such that you can report that the build of three.js and three.min.js failed via build.bat back to the PR: https://developer.github.com/v3/repos/statuses/

@bhouston The reason I haven't spoken about statuses is that it can deter contributors. Instead, we should want to make it easier to review PRs without enforcing the limitations. But this needs to be discussed here.

You could also run the ThreeJS unit tests and only state that the build succeeded if those succeeded as well. And you can link to their output as well. We have this for our Clara.io unit tests via Jenkins' github integration.

This is indeed some thing I'm looking into.

gero3 on 28 Sep 2015

Great stuff! 😮

@bhouston The reason I haven't spoken about statuses is that it can deter contributors. Instead, we should want to make it easier to review PRs without enforcing the limitations.

Agreed!

mrdoob on 28 Sep 2015

Very nice work! Out of interest - what tech stack did you use to build the site?

GGAlanSmithee on 28 Sep 2015

@bhouston The reason I haven't spoken about statuses is that it can deter contributors. Instead, we should want to make it easier to review PRs without enforcing the limitations.
Agreed!

But I do think we can add a comment to the PRs, something similar as

You can now view the examples here for this Pull request.

I'm just not sure as which person it should send this comment.

gero3 on 28 Sep 2015

Then always say the build passed but use the status to link to the examples. :). Then everyone will be checking it out rather than just those that remeber that it exists.

bhouston on 28 Sep 2015

Very nice work! Out of interest - what tech stack did you use to build the site?

Weirdly enough, it is azure, node, express, and file storage.

gero3 on 28 Sep 2015

Then always say the build passed but use the status to link to the examples. :). Then everyone will be checking it out rather than just those that remeber that it exists.

That is why I think sending a comment is more interesting to make people aware of this. Because wouldn't contributors start worrying when they notice the bar even when it is always green

gero3 on 28 Sep 2015

Could send it as threejworker by registering a new github account for it.

Best regards,
Ben Houston
http://Clara.io Online 3d modeling and rendering
On Sep 28, 2015 5:17 PM, "gero3" [email protected] wrote:

@bhouston https://github.com/bhouston The reason I haven't spoken about
statuses is that it can deter contributors. Instead, we should want to make
it easier to review PRs without enforcing the limitations.
Agreed!

But I do think we can add a comment to the PRs, something similar as

You can now view the examples here
http://threejsworker.com/api/pullrequests/7259/examples/index.html for
this Pull request.

I'm just not sure as which person it should send this comment.

—
Reply to this email directly or view it on GitHub
https://github.com/mrdoob/three.js/issues/7258#issuecomment-143876190.

bhouston on 28 Sep 2015

Sweet. @gero3 many thanks!

WestLangley on 29 Sep 2015

@gero3 How do you build three.js? It looks like recently added files won't make it into your three.js build. See e.g. http://threejsworker.com/api/pullrequests/5402/examples/index.html#webgl_rtt_depth

kintel on 30 Sep 2015

Due to refactoring I broke the builder, which is why I didn't work. But it is fixed now. It is still a first version. I'll add more logging to the system to make sure it keeps on working for in the future.

Btw thanks for adding the first reference to it.

gero3 on 30 Sep 2015

Maybe we should create a threejsworkerworker that tests builds of threejsworker to ensure that they are okay before deploying?

bhouston on 30 Sep 2015

Thanks! This really saved me from a bunch of work building and testing stuff locally!

kintel on 30 Sep 2015

@kintel Do you mind explaining your workflow for using this tool to test a feature branch? Thanks.

WestLangley on 30 Sep 2015

@WestLangley When testing an external feature branch I would usually check it out, build it, edit the examples to use non-minimized versions of three.js, load relevant examples in a browser which is configured to handle file URLs, then inspect any issues arising using dev tools. Then keep another few clones of three.js around for other feature branches and compare. This tool reduces most of that workflow to only one step.
When testing my own feature branch, I would simply use this as a sanity check to see that it works in a clean environment, plus making it easy to point other people to it - i.e. visual CI.

kintel on 30 Sep 2015

@kintel Got it. I do that too -- locally. I don't commit and push origin unitl I am done testing. Then I submit the PR. So the thing I am missing is how to use this tool locally. Sorry, I must be missing something obvious...

WestLangley on 30 Sep 2015

Since this tool simply looks for PR's on github, it won't work locally :)
Of course, it we can get it to also pull feature branches from my forked three.js it would be even better!

kintel on 30 Sep 2015

OK. That was what I thought. You submit the PR before you use the tool for testing. I probably would not use it for that purpose, then.

I _would_ use it as a tool for testing the PRs of other contributors, however.

WestLangley on 30 Sep 2015

@kintel I'm not going to add support for forked three.js branches in the near future.

gero3 on 11 Oct 2015

threejsworker is now updated to be more stable. The source is also released on github. The issues can be sent to that repository. Suggestion are certainly welcome. To that end, there is a small explanation in the readme to get the server running on your system.

Things that are still on the TODO list:

Figure out a decent visual design.
Add a single comment to the github pullrequest with link.
Compare PullRequests with dev/master branch with easy navigation between examples.
Integrate saucelabs
Integrate appveyor
Integrate travis
Visualize unit tests, documentation & editor link directly in grid.(You can navigate to it right now)
Figure out which files changed and act accordingly.
Lint the code

Let's make all make sure that contributing to three.js is certainly effortless :smile:

gero3 on 11 Oct 2015

Sweeeet!

mrdoob on 12 Oct 2015

This should really be http://ci.threejs.org :) I think most know but CI = continuous integration.

bhouston on 13 Oct 2015

Sounds good to me!

@gero3 if you like the idea too, let me know where I should point the subdomain to.

mrdoob on 13 Oct 2015

I agree if you don't mind pointing to threejsworker.com.
I'm actually reviewing providers to host threejsworker, pointing to threejsworker makes it easier to switch.

gero3 on 13 Oct 2015

@gero3, linode.com and digitalocean are pretty cheap -- we use both. If you want, Exocortex can help sponsor the hosting.

bhouston on 13 Oct 2015

I agree if you don't mind pointing to threejsworker.com.
I'm actually reviewing providers to host threejsworker, pointing to threejsworker makes it easier to switch.

Oks. Should work in a few hours.

mrdoob on 13 Oct 2015

I actually switched to digitalocean and this fixed the issue with cI.threejs.org.

@bhouston, thanks for the offer but I'll need to look into sponsors a later time.

gero3 on 15 Oct 2015

@gero3 I've just blocked @threejsworker because it was spamming the issues section.

screen shot 2015-10-15 at 19 38 08

Let me know when you manage to fix it and I'll unblock.

mrdoob on 16 Oct 2015

I think using the github status way of integrating threejsworker is less spammy. Status has a place to include a link to the PR results. If it says success all the time, it shouldn't scare off contributors and it doesn't show up in the comments.

bhouston on 16 Oct 2015

@bhouston you mean this API https://developer.github.com/v3/repos/statuses/, right?

Looking at the qunit repo that use a ci service this seems nice (https://github.com/jquery/qunit/pull/875). At the end of the PR you get new statuses in addition the status if the PR is mergeable or not. Also, the details view (that can link to more information) of the statuses is still available when the PR is merged.

arose on 17 Oct 2015

one way to avoid threejsworker spamming the PRs is to have it email the author instead (i believe that's travis-ci behaviour). anyone else whose viewing the PR can click on the status icon to check the status of whether the commit is build (or building or failed)...