[x3d-public] x3dom testing and building

[Andreas Plesch]

On Wed, Oct 18, 2017 at 11:34 AM, Don Brutzman <brutzman at nps.edu> wrote:
> [cc: both lists]
>
> Andreas this approach to incremental development and testing looks really
> great!  Thanks for your efforts in concert with the Fraunhofer team.

Agreed. Incremental experiments could be a more sustainable path
forward. Divide et impera.

> At some point we might further want to hook up a unit-test suite of X3D
> scenes to this BuildPR process (perhaps with requested frequency not to
> exceed once or twice per day updates).

Quite a few things will need to be figured out. But for starters,
simply having an additional x3dom test version of an (all) example
which uses

<script type="text/javascript"
src="http://x3dom-builds.surge.sh/latest/x3dom-full.js"/>

instead of

<script type="text/javascript"
src="http://www.x3dom.org/download/dev/x3dom-full.js"/>

could be really helpful. Perhaps 'latest' should really become 'testing' .

The URL does not change, and x3dom-full.js is available immediately
after building from the URL. This would be a way to manually, but
quickly check a few examples which may be impacted by a change in a
build.
So this would not require daily updates of the examples. It does
require generating a fair number of additinoal xhtml files.

There are probably better ways to get started but this could be done
quickly perhaps.

I do something similar currently with user scripts and tampermonkey
which feels clumsy.

>
> Wondering please, will there be someplace in the X3DOM developers
> documentation where your information below will be found?

Although this may be premature, I have added a page to the github x3dom wiki:

https://github.com/x3dom/x3dom/wiki/Automatic-PR-builds

and linked to it from the wiki home page.

-Andreas
>
> On 10/17/2017 6:21 AM, Andreas Plesch wrote:
>>
>> I just posted below on the x3dom-developer list but it may be
>> interesting here as well. Longer term it may become possible to use
>> the example archive for automatic testing of x3dom in addition to
>> automatic building.
>>
>> Using github it is convenient to fork x3dom and then use the online
>> editor to work on the code. To test and use the new code, it is
>> preferable to build the x3dom.js distribution with the manage.py build
>> script. This step is sometimes a hurdle because it requires cloning to
>> a local computer, setting up Python, invoking the script and uploading
>> the results. Before submitting a pull request to the main master
>> branch, it is also necessary to test the new code, preferably by
>> building a new x3dom.js .
>>
>> To help with the building step, I am setting up a special BuildPR
>> branch on my github X3DOM branch
>> (https://github.com/andreasplesch/x3dom/tree/BuildPR). The BuildPR
>> branch is synced with the main master branch and triggers automatic
>> building of x3dom whenever a PR is received against it. This is all
>> done on the travis ci service. The build is then deployed to
>> x3dom-builds.surge.sh/latest and x3dom-builds.surge.sh/build_x . The
>> 10 most recent builds are kept under build_0 to build_9.
>> x3dom-builds.surge.sh provides a listing of all builds.
>>
>> This mostly works but Travis sometimes just stops the build process.
>> Possibly, the build script is overwhelming the logging facility.
>> Investigating. May try redirecting output to a file or /dev/null.
>>
>> I may separate out the latest, most recently requested build to its
>> own domain: x3dom-testing.surge.sh . This would be easy to do.
>>
>> It would be useful to try this build service by just retargeting
>> existing PRs from the main master branch to the andreasplesch/BuildPR
>> branch. travis and/or github may behave differently when dealing with
>> PRs from forks other than the owner's. Any feedback and ideas for
>> improvement are welcome,
>>
>> Andreas
>>
>> PS: it is possible to submit a PR which modifies the build script and
>> thereby allows uploading of arbitrary content. So you can only really
>> trust the build results of your own PRs. Using other builds or other
>> files served from this domain requires the level of trust you would
>> have when using information from an unknown web site.
>
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman



-- 
Andreas Plesch
Waltham, MA 02453