| |
when I run jq .event_queue_length reports/status.json
|
| |
then stdout is exactly "0\n"
|
| |
~~~
|
| + |
# Acceptance criteria for upgrades
|
| + |
|
| + |
_What:_ The node operator can safely upgrade the CI broker. At the
|
| + |
very least, the CI broker developers need to know if they are making a
|
| + |
breaking change.
|
| + |
|
| + |
_Why:_ If software upgrades are tedious or risky, they happen less
|
| + |
often, to the detriment of everyone.
|
| + |
|
| + |
_Who:_ `cib-dev`, `node-ops`
|
| + |
|
| + |
It is important that those running the CI broker can upgrade
|
| + |
confidently. This requires, at least, that CI broker upgrades in
|
| + |
existing installations do not break anything, or at least not without
|
| + |
warning. The scenario in this chapter verifies that in a simple, even
|
| + |
simplistic manner.
|
| + |
|
| + |
Note that this upgrade testing is very much in its infancy. It is
|
| + |
expected to be fleshed out over time. There will probably be more
|
| + |
scenarios later.
|
| + |
|
| + |
The overall approach is as follows:
|
| + |
|
| + |
* we run various increasing versions of the CI broker
|
| + |
* we use the same configuration file and database for each version
|
| + |
* we have an isolated test node so that the CI broker can validate
|
| + |
repository and commit
|
| + |
* for each version, we use `cibtool trigger` and `cib queued` to run
|
| + |
CI
|
| + |
* after each version, we verify that the database has all the CI runs
|
| + |
it had before running the version, plus one more
|
| + |
|
| + |
Note that because this scenario may be run outside the developer's
|
| + |
development environment, it is currently difficult to access the Git
|
| + |
tags that represent the CI broker releases. Thus we verify upgrades to
|
| + |
the Git commit identifiers instead. In any case, this scenario needs
|
| + |
to be updated when a new release is made.
|
| + |
|
| + |
~~~scenario
|
| + |
given file radenv.sh
|
| + |
given file setup-node.sh
|
| + |
when I run bash radenv.sh bash setup-node.sh
|
| + |
|
| + |
given an installed cibtool
|
| + |
given an installed cib
|
| + |
given file broker.yaml
|
| + |
given file verify-upgrade
|
| + |
given a directory reports
|
| + |
|
| + |
given file adapter.sh from dummy.sh
|
| + |
when I run chmod +x adapter.sh
|
| + |
|
| + |
when I touch file run-list.txt
|
| + |
when I run bash radenv.sh bash -x verify-upgrade run-list.txt 04ac3852a52a0256a126252b2c46dea225189441
|
| + |
when I run bash radenv.sh bash -x verify-upgrade run-list.txt 5ae4d012f2b2f3df6fbbfce9b7d739f13363d0ec
|
| + |
~~~
|
| + |
|
| + |
~~~{#verify-upgrade .file .sh}
|
| + |
#!/bin/bash
|
| + |
#
|
| + |
# Given a list of CI runs and a CI broker version, build and run that
|
| + |
# version so that it triggers and runs CI on a given change. Then
|
| + |
# verify the CI broker database has the CI runs in the list, plus one
|
| + |
# more, and then update the list.
|
| + |
|
| + |
set -euo pipefail
|
| + |
|
| + |
REPO="testy"
|
| + |
|
| + |
LIST="$1"
|
| + |
VERSION="$2"
|
| + |
|
| + |
# Unset this so that the Cargo cache doesn't get messed up. (This
|
| + |
# smells like a caching bug, or my misundestanding.)
|
| + |
unset CARGO_TARGET_DIR
|
| + |
|
| + |
# Remember where various things are.
|
| + |
db="$(pwd)/ci-broker.db"
|
| + |
reports="$(pwd)/reports"
|
| + |
adapter="$(pwd)/adapter.sh"
|
| + |
|
| + |
# Remember where the config is and update config to use correct
|
| + |
# database and report directory.
|
| + |
config="$(pwd)/broker.yaml"
|
| + |
sed -i "s,^db:.*,db: $db," "$config"
|
| + |
sed -i "s,^report_dir:.*,report_dir: $reports," "$config"
|
| + |
sed -i "s,command:.*,command: $adapter," "$config"
|
| + |
nl "$config"
|
| + |
|
| + |
|
| + |
# Get source code for CI broker. The scenario that uses this script
|
| + |
# set $SRCDIR to point at the source tree, so we get the source code
|
| + |
# from there to avoid having to fetch things from the network.
|
| + |
rm -rf ci-broker html
|
| + |
mkdir ci-broker html
|
| + |
(cd "$SRCDIR" && git archive "$VERSION") | tar -C ci-broker -xf -
|
| + |
|
| + |
# Do things in the exported CI broker source tree. Capture stdout to a
|
| + |
# new list of CI run.
|
| + |
(
|
| + |
cd ci-broker
|
| + |
|
| + |
# Build source code.
|
| + |
cargo build --all-targets -q
|
| + |
|
| + |
(echo "Old CI run lists:"
|
| + |
cargo run -q --bin cibtool -- --db "$db" run list 1>&2
|
| + |
cargo run -q --bin cibtool -- --db "$db" run list --json) 1>&2
|
| + |
|
| + |
# Trigger a CI run. Hide the event ID that cibtool writes to
|
| + |
# stdout.
|
| + |
cargo run -q --bin cibtool -- --db "$db" trigger --repo "$REPO" --name main --commit HEAD >/dev/null
|
| + |
|
| + |
# Run CI on queued events.
|
| + |
cargo run -q --bin cib -- --config "$config" queued
|
| + |
|
| + |
# List CI runs now in database.
|
| + |
cargo run -q --bin cibtool -- --db "$db" run list
|
| + |
) >"$LIST.new"
|
| + |
|
| + |
# Check that new list contains everything in old list, plus one more.
|
| + |
removed="$(diff -u <(sort "$LIST") <(sort "$LIST.new") | sed '1,/^@@/d' | grep -c "^-" || true)"
|
| + |
added="$(diff -u <(sort "$LIST") <(sort "$LIST.new") | sed '1,/^@@/d' | grep -c "^+" || true)"
|
| + |
|
| + |
if [ "$removed" = 0 ] && [ "$added" = 1 ]; then
|
| + |
echo "CI broker $VERSION ran OK"
|
| + |
mv "$LIST.new" "$LIST"
|
| + |
else
|
| + |
echo "CI broker removed $removed, added $added CI runs." 1>&2
|
| + |
exit 1
|
| + |
fi
|
| + |
~~~
|