goth and ensure it's running properly on your system.goth's repository:goth is not (yet) available as a standalone package, therefore you will need to set up its development environment in order to use it.goth uses poetry to manage its dependencies and provide a runner for common tasks (e.g. running E2E tests). If you don't have poetry available on your system then follow its installation instructions before proceeding or just install it with:goth: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 uses the GitHub API to fetch metadata and download artifacts and images. Although all of these assets are public, using the GitHub API still requires basic authentication. Therefore, you 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 (iow, don't use your regular 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.yagna can be found under test/yagna with end-to-end tests located in test/yagna/e2e. To run them, issue the below command from the project's root directory: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.poethepoet, a task runner for poetry. If you'd like see all the tasks configured in goth, run poe with no arguments:goth is pytest, therefore each test is defined as a separate Python function in a given .py file.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.