• A docker-containerized microservice for https://cyber-dojo.org.
• An HTTP Ruby Sinatra web service, offering a Group/Kata model+persistence API.
• Demonstrates a Kosli instrumented GitHub CI workflow deploying, with Continuous Compliance, to its staging AWS environment.
• Deployment to its production AWS environment is via a separate promotion workflow.
• Uses attestation patterns from https://www.kosli.com/blog/using-kosli-attest-in-github-action-workflows-some-tips/

There are two sets of tests:

• server: these run from inside the saver container
• client: these run from outside the saver container, making api calls only

# Build the images
$ make {image_server|image_client}

# Run all tests
$ make {test_server|test_client}

# Run only tests whose id starts with Sp5
$ make {test_server|test_client} tid=Sp5

# Check test metrics
$ make {metrics_test_server|metrics_test_client}

# Check coverage metrics
$ make {metrics_coverage_server|metrics_coverage_client}

A cluster is the umbrella over a multi Language-Test-Framework (LTF) practice: it offers 2..5 LTFs, holding one ordinary Group per LTF (its children). A cluster is never joined directly; a joiner joins one of its child groups.

A group is a shared practice for a single Language-Test-Framework: joiners join it, each allocated a distinct avatar (Lion, Salmon, Bee, etc) and their own Kata of the group's exercise. A group holds up to 64 katas, one per avatar. In a Cluster a group is one of the children (one per LTF).

A kata is one participant's practice: created from a manifest (an exercise for a single Language-Test-Framework), it records every event as its own git commit - the create, each file create/delete/rename/edit, and each test run with its traffic-light colour (red, amber, green). Each avatar in a Group is a kata.

Find the full Cluster/Group/Kata information of any id.

Compare a Kata's files between two event indexes.

Operational health checks, plus the git sha of the running image.