4 ms·

Has anyone had any luck adding API tests to Gilab's CI/CD pipeline? For some reason I'm able to build Docker images and run them as containers with dind as part

Has anyone had any luck adding API tests to Gilab's CI/CD pipeline? For some reason I'm able to build Docker images and run them as containers with dind as part of a testing pipeline but I haven't had any luck getting the API test scripts to establish any connection with the containerized service.

oddeyed 7y ago
I have a test suite doing this. If you can't reach the server by name then try adding an 'alias' to the service definition and then try to connect to that hostname. Good luck!
rmetzler 7y ago
This sounds like a Docker networking problem. I would think you need to have docker-compose and bring your microservice and all the dependencies up and then test against your microservice _in the same network_. I've written some .gitlab-ci.yml files in the last months. What I do is using a script to validate against the Gitlab lint API. This is done every time I save the file. I also run gitlab-runner on my local machine and test my jobs with `gitlab-runner exec docker`. Don't forget to commit what you need in the job. You don't need to commit the .gitlab-ci.yml, but everything else, because the first step to run the job is cloning the repo. I have also updated the brew formulas for the last releases of gitlab-runner. Gitlab is great software and I've worked with it and administrated it for the last 5 years. I don't want to miss it.
- BaronSamedi 7y ago
  I was also going to say it's likely a Docker network problem. Docker-in-docker runners work great for us and make it possible to do all kinds testing in the pipeline; for example Selenium, custom REST, OWASP ZAP, etc.
umvi 7y ago
You might need to add `pre_clone_script` to your runner config.toml to setup any proxies, etc. that you need.
AaronFriel 7y ago
Yes, using docker compose to ensure that all of the containers are connected to each other, or using minikube to simulate deploying a Kubernetes stack. If your test scripts are running as part of the "before_script", "script", or "after_script" block, they aren't running in the network namespace configured by Docker in Docker and won't have the same name resolution, so you'll need to port map your Docker containers and your test scripts will need to use "localhost" and ports to connect to your containers. If your tests are themselves run in a Docker container, it should work as expected.
horstmeyer 7y ago
What about just using `docker-compose exec` to get into the running API container, and then executing the tests inside of that, against localhost? Not as pretty as properly testing from an outside container, but seems by far the easiest way to solve this problem.

oddeyed 7y ago

I have a test suite doing this. If you can't reach the server by name then try adding an 'alias' to the service definition and then try to connect to that hostname. Good luck!

rmetzler 7y ago

This sounds like a Docker networking problem. I would think you need to have docker-compose and bring your microservice and all the dependencies up and then test against your microservice _in the same network_. I've written some .gitlab-ci.yml files in the last months. What I do is using a script to validate against the Gitlab lint API. This is done every time I save the file. I also run gitlab-runner on my local machine and test my jobs with `gitlab-runner exec docker`. Don't forget to commit what you need in the job. You don't need to commit the .gitlab-ci.yml, but everything else, because the first step to run the job is cloning the repo. I have also updated the brew formulas for the last releases of gitlab-runner. Gitlab is great software and I've worked with it and administrated it for the last 5 years. I don't want to miss it.

BaronSamedi 7y ago
I was also going to say it's likely a Docker network problem. Docker-in-docker runners work great for us and make it possible to do all kinds testing in the pipeline; for example Selenium, custom REST, OWASP ZAP, etc.

umvi 7y ago

You might need to add `pre_clone_script` to your runner config.toml to setup any proxies, etc. that you need.

AaronFriel 7y ago

Yes, using docker compose to ensure that all of the containers are connected to each other, or using minikube to simulate deploying a Kubernetes stack. If your test scripts are running as part of the "before_script", "script", or "after_script" block, they aren't running in the network namespace configured by Docker in Docker and won't have the same name resolution, so you'll need to port map your Docker containers and your test scripts will need to use "localhost" and ports to connect to your containers. If your tests are themselves run in a Docker container, it should work as expected.

horstmeyer 7y ago

What about just using `docker-compose exec` to get into the running API container, and then executing the tests inside of that, against localhost? Not as pretty as properly testing from an outside container, but seems by far the easiest way to solve this problem.