Checklist for running meteor and tests from jenkins

[as33ms]

We should be able to do the following from within the Jenkins job:

• Setup umbrella instance for running the tests (this instance should be flushed or seeded with test data every time test is being run OR to be discussed)
• Able to run the project using meteor and then, proceed to next step for running the Gate 1 tests

For running tests

• Configure robot
• Setup a slave that runs the UI tests
• Test data seeding for the meteor installation

Non-mandatory things:

• DNS Entry for qa.apinf.io -> 109.70.165.171 @ccsr

[as33ms]

For slave setup, it should be done using Java Web Start.

[as33ms]

@shaliko are the deployments to production and nightly servers done using mupx? If yes, can you please write down the steps?

[shaliko]

@ashakunt No, we use docker image for deploy. Ping me if you need details.

[as33ms]

@shaliko : yes please; add the information related to that here (or if it is already documented somewhere, please provide a link) (deployment part is needed for Gate2 and Gate3)

[shaliko]

@ashakunt we use docker-compose setup on nightly, you can find it here https://github.com/apinf/platform/blob/develop/docker-compose.yml and instructions here https://github.com/apinf/platform/blob/develop/INSTALL.md#with-docker-compose

Probably you need drop Let's encrypt part for Jenkins tasks, ping me if need assistance.

Additional to docker-compose setup on nightly each night executing this script:

# Cron
1 3 * * *	sh -c '/home/nightly/docker-compose.sh'

# docker-compose.sh
#!/bin/bash
cd /home/nightly && docker pull apinf/platform:develop && docker-compose stop && docker-compose up -d

#Clean up old docker images
docker rmi $(docker images -q -f dangling=true)

So script pull the latest version of Docker image based on 'develop' branch and restarts.

[as33ms]

@phanimahesh : https://stackoverflow.com/questions/23141373/run-meteor-as-a-daemon-process is interesting. Especially since our jenkins build steps would be something like:

git pull // taken care by jenkins
meteor // to deploy the commit at localhost
python -m robot 1.registering.txt 2.Login.txt 3.addapi.txt 

Or do you have any better ideas?

[shaliko]

In the script above missed installation of api-umbrella. I think that you know, just notice.

1. Or do you have any better ideas?

@ashakunt Can you please share the target of this task?

2. Why we use Jenkins if already have integration with Travis-ci?

[phanimahesh]

For deployment, meteor projects should be built properly into a plain node project, and meteor family of commands should never be used. Our docker image seems to be doing it right. (Our Dockerfile builds on that repo)

Testing environment should match production environment except for external interfaces like mail server (replaced by stubs or dummies) and data storage (separate db, seeded test data...) We can either build the docker images or replicate the same steps, more or less, without docker. Any end to end test must be run against this prod bundle. Meteor testing story anyway doesn't let us do any other kind of tests nicely, we'll worry about them later when we figure out how to write them properly.

@shaliko

1. Build the project as closely as possible to a production config, and run end to end tests.
2. Jenkins will complement travis. More extensive tests, we can poke around failed tests better (our machines, ssh and debug potentially if necessary), etc.

[shaliko]

@phanimahesh you can run docker Apinf image+MongoDB and execute robot scripts on it, that will be exactly as on production except for SSL (but that is OK).

1. I really like @mauriciovieira approach for use chimp Setup chimp on travis #2654. Looks like Jenkins setup will do the same, but with python robot - or I missed something? For developers will be easy use JS library for add/update tests in the same pull request with the new code.

2. "our machines, ssh and debug potentially if necessary" from my experience that no one from the developer will not use debug on Jenkins machine, much easier able run the same test on the local machine.

[phanimahesh]

1. robot was just a suggestion, I presume. If we have chimp based tests, we'll use the same on jenkins.
2. At this point we are not doing anything that travis can't do, but our own jenkins installation opens up new possibilities. We can trust our own machine more than travis.

[as33ms]

One more reason to use robot at this point of time is that we are using it to write the test cases for features which were already implemented and developer will not have time to write the test cases for them. Having the test-developer learn chimp first and then write, will just take time in getting tests up and running.

I agree and share the same thoghts as @phanimahesh w.r.t. Jenkins. The idea is to have more and more control over the test environment.

[shaliko]

@phanimahesh

1. Good.
2. So that something for the future. No new value right now.

@ashakunt

"developer will not have time to write the test cases for them"

In my team, we will not accept any pull request without tests. Especially that critical to bug fixes, each bug fix should be with tests in pull requests.

Will be good apply the same rule to Apinf developer team ;)

[mauriciovieira]

related #2621

[as33ms]

@shaliko : joining a bit late here but about:

"developer will not have time to write the test cases for them"

I only meant this for the features that have already been developed. For anything new, nothing gets inside without a test case.

[bajiat]

@ashakunt Is this in progress?

When the instructions have been finalised, can we add these to README in our repo?

[preriasusi]

Almost half of the year gone with this. I will now just close this. Anyone missing this, feel free to open.