OJS, OMP, and OPS Testing Datasets

This repository contains data sets generated by the integration test suite built into OJS, OMP, and OPS.

Contents

The generated datasets contain...

• One single context: a journal (OJS), a press (OMP), or a server (OPS), with basic policies, contact information, etc. Language configuration is for French and English.
• Users:
  • Administrator: username admin, password admin
  • Editor: username dbarnes, password dbarnesdbarnes
  • Additional users per these lists: OJS OMP OPS
  • By convention, the passwords are the usernames repeated twice (except for admin).
• Submissions: A variety of published and unpublished content in various stages, depending on the application

Layout

The data sets are organized in application / branch or tag name / dbms:

• application is ojs, omp, or ops
• branch name is e.g. stable-3_3_0 or 3_3_0-1
• dbms is either mysql (MySQL / MariaDB) or pgsql (PostgreSQL)

Within each dataset, you will find:

• database.sql: Database dump
• config.inc.php: OJS configuration file
• public: Directory containing the OJS public files
• files: Directory containing the OJS files_dir (In production this should not be web-accessible)

Tools

Note: These tools are generally intended to be run from the OJS/OMP/OPS installation directory, so you will likely have to specify the path to run them. In the examples below, this repository is available in ../datasets.

• environment.sh: Configure the shell environment.

  Example: . ../datasets/tools/environment.sh ojs main

• dbclient.sh: Connect to the database client.

  Example: ../datasets/tools/dbclient.sh < mydatadump.sql (to load a database dump)

  Example: ../datasets/tools/dbclient.sh (to run SQL statements from the terminal)

• recreatedb.sh: Ensure an empty database is available, deleting any existing data if necessary.

  Example: ../datasets/tools/recreatedb.sh (you may need to provide a sudo password)

• wipe.sh: Clear out the database, files directory, configuration file, etc. This will leave the application ready to be installed.

  Example: ../datasets/tools/wipe.sh

• loaddb.sh: Load the database image from the appropriate dataset. This will create an empty DB as needed.

  Example: ../datasets/tools/loaddb.sh (you may need to provide a sudo password)

  Example: ../datasets/tools/loaddb.sh stable-3_3_0 to load a specific database version (e.g. for upgrade testing)

• loadfiles.sh: Load the files environment from the appropriate dataset. This includes file storage area, public file storage area, and configuration file.

  Example: ../datasets/tools/loadfiles.sh

  Example: ../datasets/tools/loadfiles.sh stable-3_3_0 to load a set of files for a specific version (e.g. for upgrade testing)

• load.sh: Load both the database and file environments from the appropriate dataset. This is equivalent to running both loadfiles.sh and loaddb.sh.

  Example: ../datasets/tools/load.sh (you may need to provide a sudo password)

  Example: ../datasets/tools/load.sh stable-3_3_0 to load a specific version of a dataset (e.g. for upgrade testing)

How this is maintained

OJS, OMP, and OPS contain a Cypress test suite for setting up a test environment with standardized data (OJS OMP OPS). These are called the data tests.

Our github repositories are configured with Travis-CI for continuous integration testing -- changes to these repositories result in Travis performing tests and reporting success/failure. This includes running the data tests (but also linting, unit and integration testing, etc).

Some builds in the Travis configuration are flagged using an environment variable (SAVE_BUILD; see .travis.yml) to indicate that the data resulting from the data tests should be saved. This saving is done in run-tests.sh just after the data tests complete.

The data is transferred from the Travis VM to this github repository using a "machine user" Github account called pkp-machine-user. This user has an API token for the purpose, which is provided to Travis using an encrypted variable in .travis.yml.