FrontPage 

Fuego wiki

Login or create account

Board farm APIs in split format

Here are some resources for a "board farm APIs" project.
Here are some resources for a "board farm APIs" project.
I'd like to make my own server for REST apis for board farm stuff.
I'd like to make my own server for REST apis for board farm stuff.
I'm working with TimeSys on this project, and have proposed a talk at ELCE on the topic.
I'm working with TimeSys on this project, and have proposed a
talk at ELCE on the topic.

Here's my abstract [edit section]

== Here's my abstract ==
For years, designers of automated testing systems have used ad-hoc designs for the interfaces between a test, the test framework and board farm software, and the device under test. This has resulted in a situation where hardware tests cannot be reused from one lab to another. This talk presents a proposal for a standard API between automated tests and board farm management software. The idea is to allow a test to query the farm about available bus connections, attached hardware and monitors, and other test installation infrastructure. The test can then allocate and use that hardware, in a lab-independent fashion. The proposal calls for a dual REST/command-line API, with support for discovery, control and operation - of hardware and network resources. It is hoped that establishing a standard in this area will allow for the creation of an ecosystem of shareable hardware tests and board farm software.
For years, designers of automated testing systems have used ad-hoc designs for the interfaces between a test, the test framework and board farm software, and the device under test. This has resulted in a situation where hardware tests cannot be reused from one lab to another.  This talk presents a proposal for a standard API between automated tests and board farm management software.  The idea is to allow a test to query the farm about available bus connections, attached hardware and monitors, and other test installation infrastructure. The test can then allocate and use that hardware, in a lab-independent fashion.  The proposal calls for a dual REST/command-line API, with support for discovery, control and operation - of hardware and network resources.  It is hoped that establishing a standard in this area will allow for the creation of an ecosystem of shareable hardware tests and board farm software.

Resources [edit section]

== Resources ==
Here are some resources:
 * jq - json command line tool - https://stedolan.github.io/jq/
 * kapow - system to create REST APIs from command line tools
    * docs: https://kapow.readthedocs.io/en/latest/#
    * code: https://github.com/BBVA/kapow
TBWiki engine 1.8.3 by Tim Bird