# Acceptance criteria for event filtering

The scenarios in this chapter verify that the event filters work as

intended. Each scenario sets up the event queue with an event, and

runs `cib queued` to process the event queue, and then verifies that

CI was run, or not run, as appropriate.

In each scenario we verify by running CI twice: once to make sure the

filter allows what it should, and once to make sure it doesn't allow

what it shouldn't

## Filter predicate `Repository`

_Want:_ We can allow an event that is for a specific repository.

_Why:_ We want to constrain CI to a specific repository.

~~~scenario

given a Radicle node, with CI configured with broker.yaml and adapter dummy.sh

given a Git repository xyzzy in the Radicle node

given a Git repository other in the Radicle node

given file config.yaml from filter-repository.yaml

given file update-repoid.sh

when I run bash update-repoid.sh xyzzy config.yaml

when I run cibtool --db ci-broker.db trigger --repo xyzzy

when I run cibtool --db ci-broker.db trigger --repo other

when I run ./env.sh cib --config config.yaml queued

when I run cibtool --db ci-broker.db run list --json

then stdout contains ""repo_name": "xyzzy""

then stdout doesn't contain ""repo_name": "other""

~~~

~~~{#filter-repository.yaml .file .json}

db: ci-broker.db

adapters:

  default:

    command: ./adapter.sh

triggers:

  - adapter: default

    filters:

      - !Repository "REPOID"

~~~

~~~{#update-repoid.sh .file .sh}

#!/bin/sh

set -eu

dir="$1"

yaml="$2"

rid="$(cd "$dir" && rad .)"

sed -i "s/REPOID/$rid/g" "$yaml"

~~~