A sample app that validates some basic CircleCI features in three parallel workflows.
To run realitycheck, fork the repository and start building it on your installation of CircleCI. See Using realitycheck to validate your CircleCI installation, in the CircleCI Support Center, for details on forking the project and building it on your CircleCI installation.
Descriptions of the three workflows follow.
Tests all known resource_class
options—queries the CircleCI API to verify that jobs ran with the requested resources.
- Your instances must be large enough to accommodate these options—see our Configuration Reference for details
- The base URL of your CircleCI installation (e.g. https://circleci.com) must be specified via a
CIRCLE_HOSTNAME
project environment variable - A personal API token (see
CIRCLE_HOSTNAME/account/api
URL endpoint) must be stored as aCIRCLE_TOKEN
project environment variable
Tests the functionality of the machine
executor, Remote Docker Environment, and Docker Layer Caching.
- Tests ability to save and restore caches
- Tests writing to and reading from workspaces
- Tests the default
org-global
context (NOTE: needs a key calledCONTEXT_END_TO_END_TEST_VAR
to exist in a context calledorg-global
) - Tests multiple contexts (NOTE: needs a key called
MULTI_CONTEXT_END_TO_END_VAR
to exist in a context calledindividual-local
) - Tests upload/storage of artifacts and test results
If you have more ideas for things that should tested, please submit a PR against the open-source repository on GitHub where this project is maintained: https://github.com/circleci/realitycheck.
See the current CI status of the main repo at https://circleci.com/gh/circleci/workflows/realitycheck.
View the LICENSE file in this repository for licensing information.