Configuration options

./config/.env

You can adjust various BugHog configuration settings by creating this file. Simply copy ./config/.env.example to ./config/.env and fill in your desired configuration.

Be sure to:

• comment all unused configuration variables.
• restart BugHog (./scripts/start.sh) after every change.

Using your own MongoDB

By default, BugHog uses a MongoDB container to store data. This data is persisted in the ./database folder.

If you prefer storing data in your own MongoDB instance, fill in the following environment variables:

• BCI_MONGO_HOST
• BCI_MONGO_USERNAME
• BCI_MONGO_DATABASE
• BCI_MONGO_PASSWORD

Using binary caching

Caching binaries in between evaluations can save you some bandwidth, since a binary is downloaded at the start of each experiment. By default, BugHog doesn't cache any binaries.

However, this can be activated by setting BCI_BINARY_CACHE_LIMIT. This variable indicates how many binaries are allowed to be cached in MongoDB.

Note

Version release binaries are given priority and are never evicted, as they are the most likely to be reused for evaluation. Commit or revision binaries, on the other hand, are evicted based on their usage frequency, with the least frequently used binaries being evicted first.

Using a previous BugHog release

You can run previous release versions of BugHog.

Pulling pre-built images

Simply run docker compose up with the BUGHOG_VERSION variable.

For example, for v2.1.1:

BUGHOG_VERSION=v2.1.1 docker compose up

Building images from source

Simply checkout the tagged source code and build BugHog again before running.

For example, checkout version v2.1.1 like so:

# Checkout the appropriate tag
git checkout v2.1.1

# Build images
docker compose build
docker compose up -d --force-recreate core nginx

Note

We don't make use of the convenience scripts in ./scripts/ because you might want to checkout a version where these scripts were not yet part of the repository.