Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start integration test #39

Merged
merged 7 commits into from
Feb 4, 2016
Merged

Start integration test #39

merged 7 commits into from
Feb 4, 2016

Conversation

mrkschan
Copy link
Owner

@mrkschan mrkschan commented Feb 3, 2016

#35

@@ -0,0 +1,12 @@
FROM golang:1.5.3
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm planning a base image for testing here, but it is not finished yet: https://hub.docker.com/r/ruflin/beat-testing/

@mrkschan
Copy link
Owner Author

mrkschan commented Feb 3, 2016

@ruflin Have a look :)

A few questions:

  1. Shall we separate unit-test and integration-test in make testsuite?
  2. Shall I "teardown" the Docker containers after the test instead of "setup" the containers by stopping them before the test? If we take "teardown" approach, would that affect the CI result?

@ruflin
Copy link

ruflin commented Feb 3, 2016

  1. Yes we should separate them in the future. With the current -short flag this was not possible.
  2. The reason we have it implemented like this because with the teardown thing we had issues several time. Theoretically I would agree the teardown option is the correct one and the clean one, but it fully depends on that in a previous build everything went as expected. In any case, it should not affect the CI results.

@mrkschan
Copy link
Owner Author

mrkschan commented Feb 3, 2016

Do you mean sometimes the docker-compose stop would fail which results in false negative CI test result?

@mrkschan
Copy link
Owner Author

mrkschan commented Feb 3, 2016

Indeed, the docker-compose stop here is to reset the Nginx stats. Shall I just add a frozen stats (e.g. /fake/status) for testing instead of using real Nginx stats?

@ruflin
Copy link

ruflin commented Feb 3, 2016

It could happen in the past, that a build started to hang so docker-compose stop was never called. Be aware that these are edge cases, but it is what lead to our current implementation.

I really like to use "real" nginx to test the stats as it makes it possible to also test different versions. Be aware that docker-compose stop does not remove the volumes, docker-compose rm is needed in addition to make sure you always start "clean".

@mrkschan
Copy link
Owner Author

mrkschan commented Feb 3, 2016

Yea, I'm aware of that but Nginx keeps stats in memory so we don't have to remove the container. Asking Nginx to reload would also do the trick.

@mrkschan
Copy link
Owner Author

mrkschan commented Feb 3, 2016

Perhaps, we could also use docker-compose up --force-recreate?

@ruflin
Copy link

ruflin commented Feb 3, 2016

Good to know about nginx. I was thinking in a more general way how to handle it. --force-recreate would work for nginx but not for services that store data on volumes: docker/compose#2127

mrkschan pushed a commit that referenced this pull request Feb 4, 2016
@mrkschan mrkschan merged commit c8f99a0 into master Feb 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants