-
Notifications
You must be signed in to change notification settings - Fork 16
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
Change the current architecture #36
Comments
Sounds good! Just a question: how can we switch between the standalone and submodule mode? |
By default, the mode can be standalone, so
To use the submodule mode, you should define a path to your
I think it is not necessary to use different branches for both standalone and submodule modes because the maintenance is easier if only one branch is used. The |
Closing since #93 is landed. |
I think that the current architecture of the project is a bit complex for the current use case. There are too many components (os, app, device, testrunner) that make unnecessary dependencies. It would be nice if the number of the components could be reduced to eliminate dependencies and make the code clearer. I also prefer if the
build
andtest
could be well separated.The following diagram shows a possible new architecture that logically divides the
js-remote-test
into abuilder
and atester
parts:Builder part
The builder part would have a
resources.json
file that could hold information about git repositories, brach or commit, or a patch list that should be applied before the build:The targets of the builder module could build the appropriate softwares (OS, Flasher, Freya, ...) and flash the device (with the appropriate flasher).
Just a note: the
config
and thepatches
folders could be moved into the builder module because they are logically belong to that. (Currently, they are in the root folder).Testrunner
The testrunner module is responsible for the test execution where the targets are responsible for the target specific output processing. This part was already implemented in iotjs.
In general, js-remote-test would work in two modes. The first is a standalone mode when iotjs and jerryscript should be downloaded and used for testing. The second is a submodule mode when the containing application (iotjs, jerryscript) should be used for testing (so it's unnecessary to download iotjs or jerryscript).
@glistening @hs0225 @robertsipka What do you think about this change?
The text was updated successfully, but these errors were encountered: