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.