This file is used by [Subplot](https://subplot.tech/) to generate and

run test code as part of running `cargo test`.

# Data files shared between scenarios

## Broker configuration

_Why:_ This is helpful for the node operator to verify that

they have configured the program correctly.

Our verification here is quite simplistic, and only checks that the

output is in the JSON format. It does not try to make sure the JSON

_Why:_ This is obviously necessary. If this doesn't work,

nothing else has a hope of working.

~~~scenario

given file radenv.sh

_Why:_ This helps node operators include the version in any bug

reports.

~~~scenario

given file radenv.sh

to the web view of a "pipeline" in GitLab CI instead, from which the

user can access individual logs.

~~~scenario

given file radenv.sh

_Why:_ This helps users deal with problems themselves and

reduces the support burden on the Radicle project.

~~~scenario

given file radenv.sh

_Why:_ This helps users deal with problems themselves and

reduces the support burden on the Radicle project.

_Comment:_ This is a very basic scenario. Error handling is by nature

a thing that can always be made better. We can later add more

simpler design and less code to terminate and allow re-starting to be

handled by a dedicated system, such as `systemd`.

~~~scenario

given file radenv.sh

_Why:_ In the integration test suite, we need to start and

stop the CI broker many times. We need to easily detect errors.

We use a special magic fake node event to signal shutdown: a

`RefsFetched` event with a skipped update for a ref "`shutdown`" and

_Why:_ This is useful for diagnosis, if nothing else.

~~~scenario

given file radenv.sh

_Why:_ Test scenarios using the dummy adapter need to be

able to rely that it works.

~~~scenario

given file dummy.sh

_Why:_ Test scenarios using this adapter need to be able to

rely that it works.

~~~scenario

given file adapter-with-url.sh

_Why:_ This is needed so that it can be invoked in Subplot

scenarios.

The following scenario may only work on Linux, as it's using `pgrep`

and `nc` and those may not be portable. If so, this may need to be

_Why:_ If this doesn't work with a single process, it won't

work of multiple processes, either.

~~~scenario

given an installed cibtool

_Why:_ This is fundamental for running CI when repositories

in a node change.

~~~scenario

given file radenv.sh

_Why:_ We need at least some rudimentary performance testing.

~~~scenario

given file radenv.sh

_Why:_ This is fundamental for running CI when repositories

in a node change.

~~~scenario

given file radenv.sh

_Why:_ This is primarily useful for testing the CI broker

queuing implementation.

We verify this by adding events to the queue with `cibtool`, and then

running the CI broker and verifying it terminates after processing the

_Why:_ This is necessary, if not necessarily sufficient, for

concurrent database use to work correctly.

Due to limitations in Subplot we mange the concurrent processes using

a helper shell script,k `count.sh`, found below. It runs two

_Why:_ This is the minimum functionality needed to manage

the event queue.

We verify that this works by adding a new broker event, and then

removing it. We randomly choose the repository id for the CI broker

_Why:_ This is needed for testing, and for the node operator

to be able to do this cleanly.

~~~scenario

given an installed cibtool

_Why:_ This allows running CI on a schedule, for example. It's also

useful for CI broker development.

~~~scenario

_Why:_ This is primarily needed for testing.

~~~scenario

given an installed cibtool