• View
• Edit
• History
• Print

Status

Accessor status

A set of scripts is available that lists accessors, supporting hosts, and test results.

• https://ptolemy.berkeley.edu/accessors/reports/status/status.html - updated by the Jenkins accessors job, see Automating.

Limitations

• Accessors that subclass other accessors are not yet supported.
• The script cannot distinguish between code statements and comments. The script performs keyword searches that may match comments and infer incorrect dependencies.

Steps

The following information is collected to generate the status page:

• Accessor list
• Modules supported by each host
• Modules required by each accessor
• Accessors used in each test case
• Results of each test case

Accessor List

The accessor list is generated by scanning the accessors repository accessors/web subdirectories for Javascript files. The script does not scan the demo, hosts, jsdoc, library, obsolete, reports, styles or wiki directories. Any *.js file in any other directory is considered to be an accessor.

For Cape Code, a copy of the accessors repository is available at org/terraswarm/accessor in the Ptolemy repository.

Modules supported by each host

There are three sources of modules:

• Host-provided
• Common
• Native

Host-provided modules

In the accessors repo, the script scans: accessors/web/hosts/<hostname>/modules/ and for node, accessors/web/hosts/node/node_modules/@accessors-modules/ for file names and directory names.

For Cape Code, in the Ptolemy repo, the script scans: ptII/actor/lib/jjs/modules/ for file names and directory names.

Common modules

The common host provides some modules, which are then available to all hosts. In the accessors repo, these are determined by scanning the directory: accessors/web/hosts/common/modules

For Cape Code, the common module names are currently hardcoded.

Native modules

The node host offers querystring as a native module. Native module names are currently hardcoded.

Modules required by each accessor

The modules required by an accessor are found by looking for require() statements in the accessor source file: require('something') where something is the module name. Either single or double quotes are permissible. Note this approach does NOT work for subclassed accessors - the parent class file would also need to be scanned. Subclassed accessors are not supported at this time.

After this step, we can calculate accessors to hosts.

Accessors used in each test case

In the accessors repository, the script scans for all *.js files in test/auto directories or subdirectories. Then, each test case is scanned for accessors by looking for instantiate statements: instantiate('instancename', 'path/to/accessorname')

For Cape Code, in the Ptolemy repo, the script scans for *.xml files (Ptolemy models) in test/auto subdirectories of: ptolemy/actor/lib/jjs/modules org/terraswarm/accessor

There are many additional demos available. Only test cases are scanned at the moment.

Each test case is scanned for the XML tag that instantiates an accessor: <property name="accessorSource" class="org.terraswarm.JSAccessor$ActionableAttribute" value="path/to/accessor">

After this step, we can calculate hosts to test cases. A test case may include multiple different accessors. If a host does not support all accessors in a test case, the table entry for the host/test case pair will be left blank.

Results of each test case

The script scans the Jenkins test results on these pages:

• http://terra.eecs.berkeley.edu:8080/job/accessors/lastCompletedBuild/testReport/(root)/BrowserHost/
• http://terra.eecs.berkeley.edu:8080/job/accessors/lastCompletedBuild/testReport/NodeHost/
• http://terra.eecs.berkeley.edu:8080/job/ptII/lastCompletedBuild/testReport/ptolemy.util.test.junit/AutoTests/

The results are copied to the status page (pass, fail, or did not run) and summarized for each accessor / host pair.

Automating

To automate, we need a way to:

• Run directory-scanning scripts upon repository changes:
• (cd accessors/web; node reports/status/calculateAccessorMap.js)
  • Creates ./reports/status/accessorMap.txt
• (cd $PTII; node org/terraswarm/accessor/status/calculateAccessorMapCapeCode.js)
  • Creates $PTII/org/terraswarm/accessor/status/accessorMapCapeCode.txt

The accessors/web/build.xml ant file has an status target that runs the above two commands.

• reports/status requires three files, which are also created by the status target:
  • reports/status/browserhost.txt is created from http://terra.eecs.berkeley.edu:8080/job/accessors/lastCompletedBuild/testReport/(root)/BrowserHost/
  • reports/status/capecodehost.txt is created from http://terra.eecs.berkeley.edu:8080/job/ptII/lastCompletedBuild/testReport/ptolemy.util.test.junit/AutoTests/
  • reports/status/nodehost.txt is created from http://terra.eecs.berkeley.edu:8080/job/accessors/lastCompletedBuild/testReport/NodeHost/

Note that the urls in accessors/web/build.xml should be the same as the ones in accessors/web/reports/status/status.js

The accessors Jenkins job invokes ant status to complete the above two steps.

• Import test data in a cross-origin manner

The accessors repository is hosted on moog@eecs.berkeley.edu and the test data is hosted on terra.eecs.berkeley.edu.

Browsers generally prohibit Javascript from fetching data from a different server, unless expressly permitted. Two options are to allow cross-origin requests by setting the Access-Control-Allow-Origin header on terra to allow moog, or by copying the status output to a file on moog.

The solution here is that the accessors Jenkins job is configured to copy the necessary files.

In the Post-build Actions section configuration, we have:

Or, if you have root access to moog, you can add your public ssh key to /home/vc/.ssh/authorized_keys2 and as yourself, run