forked from toolshed/docs.coopcloud.tech
		
	docs: bats from source & tags
This commit is contained in:
		| @ -24,10 +24,21 @@ Please use the [conventional commit format](https://www.conventionalcommits.org/ | |||||||
|  |  | ||||||
| We use [`bats`](https://bats-core.readthedocs.io/en/stable/), you can install | We use [`bats`](https://bats-core.readthedocs.io/en/stable/), you can install | ||||||
| the required dependencies with the following. You also need a working | the required dependencies with the following. You also need a working | ||||||
| installation of Docker and Go. | installation of Docker and Go (not covered in this section). | ||||||
|  |  | ||||||
| ``` | ``` | ||||||
| apt install bats bats-file bats-assert bats-support jq make git | apt install bats-file bats-assert bats-support jq make git | ||||||
|  | ``` | ||||||
|  |  | ||||||
|  | Unfortunately, the latest `bats` version in Debian stable does not have the | ||||||
|  | "filter tests by tags" feature, which is very handy for running a subset of the | ||||||
|  | tests. For this, we need to install `bats` from source. It's easy: | ||||||
|  |  | ||||||
|  | ``` | ||||||
|  | apt purge -y bats | ||||||
|  | git clone https://github.com/bats-core/bats-core.git | ||||||
|  | cd bats-core | ||||||
|  | sudo ./install.sh /usr/local | ||||||
| ``` | ``` | ||||||
|  |  | ||||||
| Then you can run the integration test suite with the following: | Then you can run the integration test suite with the following: | ||||||
| @ -44,22 +55,18 @@ It's advised that you re-use the same server and therefore the same Traefik | |||||||
| deployment for running your integration tests. Then you'll have more stable | deployment for running your integration tests. Then you'll have more stable | ||||||
| results. | results. | ||||||
|  |  | ||||||
| If you're hacking on the tests, you can speed things up with the following. |  | ||||||
|  |  | ||||||
| ``` |  | ||||||
| export ABRA_SKIP_TEARDOWN=1 |  | ||||||
| ``` |  | ||||||
|  |  | ||||||
| This will avoid nuking `$ABRA_DIR` for each test which avoids the costly `git |  | ||||||
| clone` of the catalogue on each test run. For the actual CI testing, we |  | ||||||
| probably want this clean slate on each test to avoid confusion. |  | ||||||
|  |  | ||||||
| You can filter on test names to run specific kinds of tests. | You can filter on test names to run specific kinds of tests. | ||||||
|  |  | ||||||
| ``` | ``` | ||||||
| bats tests/integration --filter "validate app argument" | bats tests/integration --filter "validate app argument" | ||||||
| ``` | ``` | ||||||
|  |  | ||||||
|  | You can filter on tags also. | ||||||
|  |  | ||||||
|  | ``` | ||||||
|  | bats tests/integration --filter-tags fast | ||||||
|  | ``` | ||||||
|  |  | ||||||
| ## Using the `abra` public API | ## Using the `abra` public API | ||||||
|  |  | ||||||
| Warning, there is currently no stability promise for the `abra` public API! Most of the internals are exposed in order to allow a free hand for developers to try build stuff. If people start to build things then we can start the discussion on what is useful to have open/closed and keep stable etc. Please let us know if you depend on the APIs! | Warning, there is currently no stability promise for the `abra` public API! Most of the internals are exposed in order to allow a free hand for developers to try build stuff. If people start to build things then we can start the discussion on what is useful to have open/closed and keep stable etc. Please let us know if you depend on the APIs! | ||||||
|  | |||||||
		Reference in New Issue
	
	Block a user