|
33 | 33 | {% endraw %} |
34 | 34 | {% endhighlight %} |
35 | 35 |
|
36 | | -This pipeline will run integration tests during thefreestype step called`my_integration_tests` and at that point a Redis instance will be available at hostname`my-redis-db-host` and port 6479. Note how in this example, the service container is placed at the root of the pipeline (as opposed to inside a specific step). This ensures that the Redis instance is running for[the duration of the pipeline]({{site.baseurl}}/docs/codefresh-yaml/service-containers/#running-services-for-the-duration-of-the-pipeline). |
| 36 | +This pipeline will run integration tests during thefreestyle step called`my_integration_tests` and at that point a Redis instance will be available at hostname`my-redis-db-host` and port 6479. Note how in this example, the service container is placed at the root of the pipeline (as opposed to inside a specific step). This ensures that the Redis instance is running for[the duration of the pipeline]({{site.baseurl}}/docs/codefresh-yaml/service-containers/#running-services-for-the-duration-of-the-pipeline). |
37 | 37 |
|
38 | 38 | ##Launching multiple sidecar containers |
39 | 39 |
|
@@ -154,7 +154,7 @@ This pipeline: |
154 | 154 |
|
155 | 155 | 1. Starts a single Redis instance |
156 | 156 | 1. Saves some data in the first step on the pipeline |
157 | | -1. Runs an unrelated step (that itself is not using the redisinstace) |
| 157 | +1. Runs an unrelated step (that itself is not using the redisinstance) |
158 | 158 | 1. Reads the data saved in the third steps |
159 | 159 |
|
160 | 160 | If you run this pipeline you will see that that data read in the third step of the pipeline was the same one as the data saved in the first step. |
@@ -261,7 +261,7 @@ steps: |
261 | 261 | {% endraw %} |
262 | 262 | {% endhighlight %} |
263 | 263 |
|
264 | | -Note that in this case the`docker-compose.yml` file must mention[speficic images](https://docs.docker.com/compose/compose-file/#image) (and not use[buildpropertes](https://docs.docker.com/compose/compose-file/#build)). |
| 264 | +Note that in this case the`docker-compose.yml` file must mention[specific images](https://docs.docker.com/compose/compose-file/#image) (and not use[buildproperties](https://docs.docker.com/compose/compose-file/#build)). |
265 | 265 |
|
266 | 266 |
|
267 | 267 | ##Launching a custom service |
@@ -305,7 +305,7 @@ steps: |
305 | 305 |
|
306 | 306 | Here a Dockerfile for a backend application is built on the spot and then is launched as sidecar container in the next step (with a hostname of`my_backend_app`). Notice that the`image` property in the sidecar service actually refers to a[Codefresh variable]({{site.baseurl}}/docs/codefresh-yaml/variables/) that holds the name of the build step. |
307 | 307 |
|
308 | | -We then run a`curl` command against the sidecar container to verify the correct health of the application. This is a great way to run integration tests againstmultilple microservices. |
| 308 | +We then run a`curl` command against the sidecar container to verify the correct health of the application. This is a great way to run integration tests againstmultiple micro-services. |
309 | 309 |
|
310 | 310 |
|
311 | 311 | ##Checking readiness of a service |
@@ -412,7 +412,7 @@ In summary `readiness` make sure that your services are actually up before you u |
412 | 412 | A very common scenario when using databases in integration tests is the need to preload some test data in the database. |
413 | 413 | While you could do that in a normal pipeline step, sidecar services have a special`setup` block for this purpose. This way not only you can make sure that the database is up (using the`readiness` property explained in the previous section) but also that it is preloaded with the correct data. |
414 | 414 |
|
415 | | -To use thiscapabily add a`setup` block in your pipeline service container: |
| 415 | +To use thiscapability add a`setup` block in your pipeline service container: |
416 | 416 |
|
417 | 417 | `codefresh.yml` |
418 | 418 | {% highlight yaml %} |
|