I am trying to integrate with Sauce Labs to run my project's Protractor tests, using CircleCI's guide as a basis. The tests are wrapped in a Grunt task, which runs flawlessly on my machine:
grunt.registerTask('test:protractor', [
'ngconstant:dev',
'modernizr:prod',
'sass',
'protractor'
]);
This is my circle.yml file:
dependencies:
pre:
- sudo apt-get update; sudo apt-get install ruby-sass
- npm install -g bower
- bower install
post:
- wget https://saucelabs.com/downloads/sc-latest-linux.tar.gz
- tar -xzf sc-latest-linux.tar.gz
test:
override:
- cd sc-*-linux && ./bin/sc --user $SAUCE_USERNAME --api-key $SAUCE_ACCESS_KEY --readyfile ~/sauce_is_ready:
background: true
# Wait for tunnel to be ready
- while [ ! -e ~/sauce_is_ready ]; do sleep 1; done
- grunt test:protractor
background: true
post:
- killall --wait sc # wait for Sauce Connect to close the tunnel
The Sauce Connect proxy clearly works according to build output:
30 May 18:18:46 - Started scproxy on port 35557.
30 May 18:18:46 - Please wait for 'you may start your tests' to start your tests.
30 May 18:19:03 - Provisioned tunnel:4b38b707d2174ebf9714f05cd8c06f79
30 May 18:19:03 - Using no proxy for connecting to tunnel VM.
30 May 18:19:03 - Starting Selenium listener...
30 May 18:19:03 - Establishing secure TLS connection to tunnel...
30 May 18:19:03 - Selenium listener started on port 4445.
30 May 18:19:04 - Sauce Connect is up, you may start your tests.
But at that point, it totally stalls. No effort to call grunt test:protractor, no activity whatsoever. After 10 minutes I killed the build.
What am I missing from this configuration to run Protractor tests through the Sauce Labs proxy?
Maybe you forgot to install grunt
dependencies:
pre:
- npm install -g grunt
Related
I'm developing some Firestore security rules locally. I use mocha to test the rules, and locally everything works. I've a Jenkins pipeline that every time I merge a PR on develop it published the rules on Firebase in cloud. What I want to do is running my unit tests within Jenkins. Anyway, every time Jenkins calls yarn test from the pipeline, I get an error that says
#firebase/firestore: Firestore (7.18.0): Could not reach Cloud Firestore backend. Connection failed 1 times. Most recent error: FirebaseError: [code=internal]: 13 INTERNAL: Received RST_STREAM with code 2 triggered by internal client error: Protocol error
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.
Is there a way to run the firebase emulators from Jenkins?
Thanks!
I found a way to do that.
By using firebase-tools-docker I can easily run my tests inside a docker container that brings up the emulators suite.
The Jenkinsfile goes like this:
def jenkinsUser = 1001
def firebaseDocker = 'andreysenov/firebase-tools:9.14.0'
stage('Pull docker image') {
sh "docker pull $firebaseDocker"
}
stage('Unit tests') {
sh "docker run -d --rm \
--user $jenkinsUser:$jenkinsUser \
-p 8080:8080 \
-v ${pwd()}:/home/node \
--name firebase-emulators \
$firebaseDocker \
firebase emulators:start"
sleep(5)
sh "docker exec firebase-emulators /bin/bash -c 'cd tests && yarn test'"
sh "docker stop firebase-emulators"
}
This is my folder structure (for reference):
Hope this helps 😉
My tests are written in mocha and they work fine when I invoke the tests using practical meteor like so:
meteor test --full-app --driver-package practicalmeteor:mocha --port 4000 --settings test_settings.json
But when I try to use dispatch:mocha-phantomjs, only the server side tests run:
meteor test --once --full-app --driver-package dispatch:mocha-phantomjs --settings test_settings.json
Am I just missing something about the separation of meteor client and server?
I am trying to use Travis for CI so I need to switch my tests over to the command line output rather than browser
From my meteor/versions
dispatch:mocha-phantomjs#0.1.6
dispatch:phantomjs-tests#0.0.5
practicalmeteor:chai#2.1.0_1
practicalmeteor:loglevel#1.2.0_2
practicalmeteor:mocha#2.4.5_3
practicalmeteor:mocha-core#1.0.1
practicalmeteor:sinon#1.14.1_2
I am using the 2.4.5 rc3 of practical meteor because of a bug that appears when dispatch and practical meteor exist in the same package file
Thanks!
I ended up using spacejam/practicalmeteor:mocha-console-runner to get my client tests to run in travis. I am posting my .travis.yml for anyone interested.
sudo: true
language: node_js
before_install:
- npm install -g spacejam
- echo $METEOR_SETTINGS > test_settings.json
# assumes that meteor is not installed
# - curl https://install.meteor.com | /bin/sh
# if meteor has been properly cached
- sudo ln -s $HOME/.meteor/meteor /usr/local/bin/meteor
cache:
directories:
- node_modules
- $HOME/.meteor/
before_script:
- meteor npm install
script:
- spacejam test --full-app --once --driver-package practicalmeteor:mocha-console-runner --settings test_settings.json
As claimed at their website Gitlab can be used to auto deploy projects after some code is pushed into the repository but I am not able to figure out how. There are plenty of ruby tutorials out there but none for meteor or node.
Basically I just need to rebuild an Docker container on my server, after code is pushed into my master branch. Does anyone know how to achieve it? I am totally new to the .gitlab-ci.yml stuff and appreciate help pretty much.
Brief: I am running a Meteor 1.3.2 app, hosted on Digital Ocean (Ubuntu 14.04) since 4 months. I am using Gitlab v. 8.3.4 running on the same Digital Ocean droplet as the Meteor app. It is a 2 GB / 2 CPUs droplet ($ 20 a month). Using the built in Gitlab CI for CI/CD. This setup has been running successfully till now. (We are currently not using Docker, however this should not matter.)
Our CI/CD strategy:
We check out Master branch on our local laptop. The branch contains the whole Meteor project as shown below:
We use git CLI tool on Windows to connect to our Gitlab server. (for pull, push, etc. similar regular git activities)
Open the checked out project in Atom editor. We have also integrated Atom with Gitlab. This helps in quick git status/pull/push etc. within Atom editor itself. Do regular Meteor work viz. fix bugs etc.
Post testing on local laptop, we then do git push & commit on master. This triggers auto build using Gitlab CI and the results (including build logs) can be seen in Gitlab itself as shown below:
Below image shows all previous build logs:
Please follow below steps:
Install meteor on the DO droplet.
Install Gitlab on DO (using 1-click deploy if possible) or manual installation. Ensure you are installing Gitlab v. 8.3.4 or newer version. I had done a DO one-click deploy on my droplet.
Start the gitlab server & log into gitlab from browser. Open your project and go to project settings -> Runners from left menu
SSH to your DO server & configure a new upstart service on the droplet as root:
vi /etc/init/meteor-service.conf
Sample file:
#upstart service file at /etc/init/meteor-service.conf
description "Meteor.js (NodeJS) application for eaxmple.com:3000"
author "rohanray#gmail.com"
# When to start the service
start on runlevel [2345]
# When to stop the service
stop on shutdown
# Automatically restart process if crashed
respawn
respawn limit 10 5
script
export PORT=3000
# this allows Meteor to figure out correct IP address of visitors
export HTTP_FORWARDED_COUNT=1
export MONGO_URL=mongodb://xxxxxx:xxxxxx#example123123.mongolab.com:59672/meteor-db
export ROOT_URL=http://<droplet_ip>:3000
exec /home/gitlab-runner/.meteor/packages/meteor-tool/1.1.10/mt-os.linux.x86_64/dev_bundle/bin/node /home/gitlab-runner/erecaho-build/server-alpha-running/bundle/main.js >> /home/gitlab-runner/erecaho-build/server-alpha-running/meteor.log
end script
Install gitlab-ci-multi-runner from here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/linux-repository.md as per the instructions
Cheatsheet:
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-ci-multi-runner
sudo gitlab-ci-multi-runner register
Enter details from step 2
Now the new runner should be green or activate the runner if required
Create .gitlab-ci.yml within the meteor project directory
Sample file:
before_script:
- echo "======================================"
- echo "==== START auto full script v0.1 ====="
- echo "======================================"
types:
- cleanup
- build
- test
- deploy
job_cleanup:
type: cleanup
script:
- cd /home/gitlab-runner/erecaho-build
- echo "cleaning up existing bundle folder"
- echo "cleaning up current server-running folder"
- rm -fr ./server-alpha-running
- mkdir ./server-alpha-running
only:
- master
tags:
- master
job_build:
type: build
script:
- pwd
- meteor build /home/gitlab-runner/erecaho-build/server-alpha-running --directory --server=http://example.org:3000 --verbose
only:
- master
tags:
- master
job_test:
type: test
script:
- echo "testing ----"
- cd /home/gitlab-runner/erecaho-build/server-alpha-running/bundle
- ls -la main.js
only:
- master
tags:
- master
job_deploy:
type: deploy
script:
- echo "deploying ----"
- cd /home/gitlab-runner/erecaho-build/server-alpha-running/bundle/programs/server/ && /home/gitlab-runner/.meteor/packages/meteor-tool/1.1.10/mt-os.linux.x86_64/dev_bundle/bin/npm install
- cd ../..
- sudo restart meteor-service
- sudo status meteor-service
only:
- master
tags:
- master
Check in above file in gitlab. This should trigger Gitlab CI and after the build process is complete, the new app will be available # example.net:3000
Note: The app will not be available after checking in .gitlab-ci.yml for the first time, since restart meteor-service will result in service not found. Manually run sudo start meteor-service once on DO SSH console. Post this any new check-in to gitlab master will trigger auto CI/CD and the new version of the app will be available on example.com:3000 after the build is completed successfully.
P.S.: gitlab ci yaml docs can be found at http://doc.gitlab.com/ee/ci/yaml/README.html for your customization and to understand the sample yaml file above.
For docker specific runner, please refer https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
We have build our first Nodejs app and I want to integrate Jenkins as continuous integration we are running node server behind Nginx as proxy and source control in Gitlab. I need example configurations or steps.
I am looking here any doc or wiki link or if you can point me into right direction it will be helpful
I have CentOS server and managed to install and configure Jenkins but not getting the proper way to connect my Gitlab server. I need to run npm commands after each build. If any one already has done that please let me know.
Thanks
Your question is still vague but I will try to provide you here how I had done Jenkins NodeJs with Gitlab integration. I have CentOS 6 and tested.
Steps
Open Java should be installed prior.
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
sudo service jenkins start
Login as jenkins
sudo -s -H -u jenkins
Now generate the ssh key in the folder /var/lib/jenkins/.ssh and copy that key to gitlab
ssh-keygen
Install Gitlab Hook Plugin and GitLab Plugin in jenkins.
As you will create a project by accessing your jenkins in browser
After creating the project go to configure (left side menu) project page
There lots of options are self explanatory - setup Git repo url
and setup mail git browser url.
Create a new item in jenkins and add the git repo url and in build triggers
select Build when a change is pushed to GitLab. GitLab CI Service URL:
Build Triggers
check the option
Build when a change is pushed to GitLab
Paste that url in your gitlab repo's webhooks in settings.
This is to run npm commands after build
There is one section SSH Publisher
In exec commands section (I have put my example you can write your commands)
cd project_dir
rm -rf public server package.json
tar -xvf projectname.tgzÂ
ls
npm install --production
export NODE_ENV=production
forever restartall
jasmine-node spec/api/frisbyapi_spec.js
rm -rf projectname.tgzÂ
I have written most the steps that I took to setup jenkins nodejs and gitlab.
I might have forgot any step. If you face any error please post that as well.
I am specifically talking about an app bundle running on my own server.
I have a Meteor app running using forever in ~/bundle and my git repo is at ~/project. I keep different release bundle tarballs in ~/release.
~/release
|-0.1.0.tar.gz
|-0.1.1.tar.gz
|-0.2.0.tar.gz
After pulling in changes from git and switching to the latest release, I want to bundle my new version and take advantage of hot-code reloading and (hopefully?) keeping client connections alive. What is the best way to do this?
Note: I am also using nginx; so will this affect the process in any way? i.e. will it kill open client connections? do I have to reload nginx after updating to newer app version?
Thanks.
You could use a script like this.
Make sure define your server in your ssh config file, e.g
Host yourserver
User youruser
Port 22
Hostname yourapp.com
IdentityFile ~/.ssh/yourkeyfile.pem
TCPKeepAlive yes
IdentitiesOnly yes
Then you could have a bash script like this:
#!/bin/bash
cd ~/Desktop/yourappdirectory
rm -f ~/Desktop/yourapp.tar.gz
meteor bundle ~/Desktop/yourapp.tar.gz
scp ~/Desktop/yourapp.tar.gz yourserver:~/yourapp.tar.gz
ssh yourserver <<'ENDSSH'
cd ~/
tar -xzf yourapp.tar.gz
sudo rm -rf yourapp
mv bundle yourapp
cd yourapp/programs/server/node_modules
rm -rf fibers
rm -rf bcrypt
sudo npm install fibers#1.0.1
sudo npm install bcrypt
cd ~/yourapp/programs/server/npm/mongo-livedata/main
rm -r mongodb
sudo npm install mongodb#1.4.1
cd ~/
sudo forever stop ~/yourapp/main.js
sudo MONGO_URL=mongodb://user:pass#ip:27017/meteor PORT=3000 ROOT_URL=https://yoursite.com forever start ~/yourapp/main.js
ENDSSH
Then just run the bash and it would upload and deploy your app for you. Just a note I couldn't put a release version in so stuff just uploads to ~/yourapp.tar.gz then unbundles into ~/yourapp
The meteor app would then be hot code reloaded on any clients if they're on the site.