Webapp test

[ThibautGery]

In order to easily run the tests of the web application

• Run the middleware (mongo & elasticsearch) on the correct port using docker
• Add the commands in the readme

[ThibautGery]

The build failed for a weird reason:
On the second container, it couldn't set nodeJS version (which must not be necessary since, there is no nodeJS application anymore ?)

Version '0.10.40' not found - try `nvm ls-remote` to browse available versions.
nvm install 0.10.40 && nvm alias default 0.10.40 returned exit code 3
Action failed: set node.js version to 0.10.40

[GUI]

Thanks for the contribution!

That CircleCI test failure is really odd. I think it must have been a temporary fluke on CircleCI's end. After triggering a retry in Circle it looks like it's successfully building (although, unfortunately it took 2 retries, since the first one errored on some integration tests that do seem to randomly fail in the CI environment--we obviously need to debug that to eliminate those).

I did have some questions/comments about this pull request:

• Are you using Vagrant development environment for development? Or are you running things directly on your computer? The Vagrant development environment should already provide ElasticSearch and MongoDB running on the appropriate ports, but if you're interested in developing without Vagrant, that would be great to know. If you are running without Vagrant, are you only running the web-app Rails application or are you also running the full stack (nginx, etc) locally?
  • More generally, we are still trying to figure out how to best leverage Docker, so if you have any suggestions, we're open to suggestions. For running API Umbrella (rather than developing), we have a Docker container, but I think we're also still interested in providing system packages (RPMs and DEBs), so that may complicate things a bit versus providing a Docker-only solution.
  • It would be nice to figure out better ways to leverage Docker for the development environment like what you've done here, since the Vagrant environment does take quite a while to setup the first time (since we need to compile a bunch of things from source). This looks good for the web app, and maybe we start there, but I'm just trying to think of how this looks with the rest of our non-Rails components (and how it also integrates with our RPM/DEP build/packaging process).
• Was there a reason for ignoring the Gemfile.lock file? We actually do commit that file to our repo and want to track changes. I typically take the approach of only ignoring Gemfile.lock when working on gems, but if you were running into any issues with this, let us know..
• For the IDEA gitignore additions, I think we'd actually prefer to keep those out of our application gitignore files and move those into a global gitignore file that's specific to your computer. If you haven't used global gitignores before, they're actually quite handy, since then you only have to set your editor ignores once on your computer (rather than in each project). It also means we don't have to track all the possible combination of tempfiles different editors might generate for different developers on the project.

Sorry for the long response, but does all that make sense? Let us know if you have any questions. But thanks again for diving in and for the contributions!

[GUI]

Oh, and regarding NodeJS in the tests (what Circle was complaining about), NodeJS is still used by our test suite for the proxy layer and full stack integration tests (eg, with all the components like nginx running). These are the tests located in the top-level test directory.

These tests are still in NodeJS primarily because it allowed us to keep our test suite the same as we underwent the transition to Lua/OpenResty. By keeping the test suite consistent, it helped give us a lot more confidence in that transition, since we could run the exact same tests against our old and new stack simultaneously.

But now that have completed that transition, I think whether NodeJS is the best fit longer-term for those types of proxy tests is a good question (since it adds another language to the mix). I'll add this to the roadmap of things to consider (although we don't have any immediate plans to change those tests, since there are a lot of them).

Hope that makes sense, but sorry for the confusion!

[ThibautGery]

Thanks you for your feedback:

• I am not using the Vagrant, I will setup the environment and look at it. I am only working with the web application for the moment. I will see if I can easily setup a docker conf for the dev (if its easier to use)
• For the Gemfile.lock I didn't saw it, So I assumed it wasn't commited. My bad
• For my IDE setup, I didn't know I will gladly setup it. Thanks

I will revert my first two commits
I spend a bit of time to discover how to run the tests. Should I let the README.MD explanation (with the docker-compose.yml) or just point to the developer documentation ? With the command to run ?

I understand about the tests in nodejs.

You run the tests in the vagrant VM ?

[ThibautGery]

ping @GUI

[GUI]

👍 Thanks!

Yes, we run tests within the Vagrant VM. I added some additional docs about running the tests here (sorry this wasn't well documented): https://api-umbrella.readthedocs.io/en/latest/developer/testing.html

So assuming we can get the Vagrant environment working for you, then running tests inside the Vagrant VM might be the best supported option, since it has the full environment for running both the web-app tests, as well as the proxy/integration tests.

However, I am still interested in this Docker testing environment for the web-app you've setup, since that would seem to have benefits over the vagrant environment (which is slow to setup and sometimes finicky to get initially built). So I've gone head and merged this, but tried to clarify that this approach isn't fully supported for the entire test suite.

But if you are just focused on the web-app, and this setup working for you, then I'd go ahead and use this approach if it's easier than the Vagrant environment. And separate from this, I think we can continue to look into what a full Docker development environment might look like for the rest of the stack (which would hopefully make getting started with development quicker and easier).