Add a new architecture for the js-remote-test.

[rtakacs]

No description provided.

[rtakacs]

Current status (2018.02.08):

Builder part:

• IoT.js support for stm32f4dis, rpi2, artik053 targets.
• JerryScript support for stm32f4dis, rpi2, artik053 targets.

Note: it was needed to modify the build methods of both NuttX and TizenRT targets. Now, all the targets can be compiled with tools/build.py that helps to use the same method in js-remote-test.

• Modify the build method of NuttX target. jerryscript#2154
• Modify the build method of TizenRT target jerryscript#2164

• Download the dependencies dynamically.
  • Just the necessary projects are downloaded.
• Submodule support. (Remove circular dependencies.)
  • js-remote-test can work in standalone mode [iotjs or jerry is downloaded] and also can work in submodule mode, when an existing iotjs and jerry can be used for testing.
• Flash support for stm32f4dis, rpi2, artik053 targets.

Testrunner part:

• IoT.js support for stm32f4dis, rpi2, artik053 targets.
• JerryScript support for stm32f4dis, rpi2, artik053 targets.

[glistening]

@rtakacs Please fix travis error (missing sign-off).

[rtakacs]

Okay, I'm finished with the rework :)

The new architecture helps to cover almost all requirement that are defined in #39.

[zherczeg]

Uh super big patch. Great work!

[rtakacs]

Some useful information to the development:

Before, js-remote-test had static (non-modifiable) paths in the paths.py file. Since those paths could not be overridden, js-remote-test could not be a sub-module of either IoT.js or JerryScript.

Now, js-remote-test can use dynamic (modifiable) paths that the user can override. The base concept is to have a resources.json file that has almost all information of the projects.
The information in the resources.json file:

• dependency list: helps to define which projects should be downloaded for the target. (Before, all projects were downloaded no matter what was the target.)
• paths: Since many paths are depend on the application and the device name, symbolic paths were introduced. This means that the subs-strings that stats with % character, should be resolved to the appropriate value.
  e.g. %result-path/%app/%device will be resolved to /home/path/to/js-remote-test/results/iotjs/artik053 and in the code it is enough just refer as env['paths']['results']. So it doesn't need to concatenate paths in the python code that makes the code more cleaner and readable.
• modules: this section defines all information about the used projects. For example where to download, which branch or tag should be used, dynamic paths related to the project, which files should be copied to the project to be configured and finally, which patches should be applied for testing the application.
  Need to mention that modules can refer to each other in their paths. For example, %iotjs defines the path to the iotjs module.

So the first step is to read the resources.json file and resolve all the symbolic paths. After that, this information is extended with the user defined options. This object can be a testing environment because it has all the necessary information (user options, project information) that required the test system.

The builder part of the test system is responsible to create profile builds (on clean repositories) and a test build (when all the patches are applied to the projects). The created binaries are copied to a top level build folder. The following diagram shows how looks the build folder like when IoT.js is compiled for the stm32f4dis device:

js-remote-test
    +-- build
          +-- iotjs
               +-- stm32f4dis
                     +-- nuttx.bin
                     +-- linker.map
                     +-- build.json
                     +-- profiles
                           +-- minimal
                           |    +-- nuttx.bin
                           |    +-- linker.map
                           +-- target
                                +-- nuttx.bin
                                +-- linker.map

Since the binary sizes are estimated by the linker map file, that files are also saved. The build.json file is created after the build step that holds the binary sizes and information about the git repositories (e.g. used hashes, date, author, commit messages).

The testrunner part is almost the same as before, just updated to use the testing environment object.

[zherczeg]

LGTM. Patch is pretty big, but looks ok. If it works, we can work on the smaller issues later.

[yichoi]

LGTM