goth
and ensure it's running properly on your system.hello-world
Docker image:goth
requires docker-compose
version 1.27 or higher. There are two ways you can install it:PATH
.docker-compose
installed to your goth
Python environment (you will need to activate the environment in the shell from which you run your tests).goth
is currently based on Docker Compose version 1, it is most likely incompatible with Compose version 2.goth
is available as a PyPI package. To install it in your Python environment run the following command:pyenv
, poetry
and virtualenvwrapper
.goth
uses the GitHub API to fetch metadata and download artifacts and images. While all of these assets are public, using the GitHub API still requires basic authentication. Therefore, you will need to provide goth
with a personal access token.public_repo
scope, as well as the read:packages
scope. The packages scope is required in order to pull Docker images from GitHub.docker login docker.pkg.github.com -u {username}
, replacing {username}
with your GitHub username and pasting in your access token as the password (do not use your GitHub password here). You only need to do this once on your development machine.GITHUB_API_TOKEN
and use the access token as its value. This environment variable will need to be available in the shell from which you run goth
.goth
and its prerequisites we can now run a local network of Golem nodes on our machine.your/output/dir
is the path to a directory under which the default assets should be created. The path can be relative and it cannot be pointing to an existing directory. These assets do not need to be re-created between test runs.docker-compose
is used to start the so-called "static" containers (e.g. local blockchain, HTTP proxy) and create a common Docker network for all containers participating in the test.docker-compose
network.Runner
object.pytest
.exe-script.json
) or payment configuration (accounts.json
).--assets-path
parameter, passing in the custom path:INFO
log level. To override it and enable more verbose logging, use the --log-cli-level
parameter:--logs-path
:--yagna-binary-path
allows you to use binaries from the local file system instead. Its value must be a path to either a directory tree containing yagna binaries (e.g. target
directory from a local cargo
build) or a .zip
archive file (e.g. downloaded manually from GitHub Actions):goth
uses a yagna
binary from the latest GitHub Actions successful build on master
branch. This option can be used to override that behaviour. The value here needs to be a git commit hash being the head for one of the build workflow runs:--yagna-deb-path
:$TEMP_DIR/goth-tests
, where $TEMP_DIR
is the path of the directory used for temporary files. This path will depend either on the shell environment or the operating system on which the tests are being run (see tempfile.gettempdir
for more details). This default location can be overridden using the option --logs-path
when running tests.runner.log
- logs recorded by the integration test runner engine.proxy.log
- logs recorded by the HTTP 'sniffer' proxy, which monitors network traffic going into the yagna daemons launched for the test.test_*
- directory with logs generated by nodes running as part of a single test (as defined in the test's topology). This directory is named after the name of the test scenario itself.provider.log
- console output from provider
yagna daemon.provider_agent.log
- console output of the provider agent, running alongside provider
daemon.