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
Related
I'm new to codeception and wonder, is it possible to run ui tests in the background, without opening test web browser every time?
I suspect, that I should change something in acceptance.suite.yml, but not sure what.
I would appreciate any help.
You can use headless browser. This will execute all the test flow almost exactly as it would work on regular UI mode while there will not be opened visual browser.
You can learn more about this here and in more similar resources.
You can use Docker to virtualize the WebDriver and Selenium.
Create two different files in the root directory. The Dockerfile will generate a container with PHP and composer to run your codeception tests in it.
Dockerfile
FROM php:8.0-cli-alpine
RUN apk -U upgrade --no-cache
# install composer
COPY --from=composer:2.2 /usr/bin/composer /usr/bin/composer
ENV COMPOSER_ALLOW_SUPERUSER=1
ENV PATH="${PATH}:/root/.composer/vendor/bin"
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --no-progress \
&& composer clear-cache
COPY . /app
RUN composer dump-autoload --optimize --classmap-authoritative \
&& composer clear-cache
The second file is docker-compose.yml which is using a preconfigured Selenium image and bound your PHP codeception tests to one network, so that the container can talk with each other over the needed ports (4444 and 7900)
docker-compose.yml
---
version: '3.4'
services:
php:
build: .
depends_on:
- selenium
volumes:
- ./:/usr/src/app:rw,cached
selenium:
image: selenium/standalone-chrome:4
shm_size: 2gb
container_name: selenium
ports:
- "4444:4444"
- "7900:7900"
environment:
- VNC_NO_PASSWORD=1
- SCREEN_WIDTH=1920
- SCREEN_HEIGHT=1080
If you setup docker and your codeception project correctly, you can run these containers in the background.
docker-compose up -d
and execute your tests:
vendor/bin/codecept run
If you want to see, what the test is doing, you can visit http://localhost:7900 to connect to the browser in the container and you can see, what the test is executing.
If you are using the WebDriver module to run your tests with codeception, there is an option to configure your browser in headless mode.
It won't open any windows and the tests will run in the background without bothering you.
There is an example with chrome :
modules:
enabled:
- WebDriver
config:
WebDriver:
url: 'http://myapp.local'
browser: chrome
window_size: 1920x1080
capabilities:
chromeOptions:
args: ["--headless", "--no-sandbox"]
I'm using Firebase to host my personal website and wanted to integrate CircleCI for faster integration. However I receive this error on the step for deployment:
Note
Adding sudo before the deploy command causes the build to fail also
/home/circleci/project/node_modules/configstore/index.js:52
throw error;
^
Error: EACCES: permission denied, open '/home/circleci/.config/configstore/firebase-tools.json'
You don't have access to this file.
Below is my project's yaml configuration:
---
commands:
restore_cache_cmd:
description: "Restore cached npm install"
steps:
- restore_cache:
key: 'dependency-cache-{{checksum "package.json"}}'
save_cache_cmd:
description: "Saving npm install"
steps:
- save_cache:
key: 'dependency-cache-{{ checksum "package.json"}}'
paths:
- "./node_modules"
update:
description: "Installing project's dependencies"
steps:
- checkout
- restore_cache_cmd
- run: sudo npm i -g npm#latest
- run: sudo npm i
- save_cache_cmd
build_deploy:
description: "Building project"
steps:
- run:
name: Build
command: sudo npm run build
- run:
name: Deploy
command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_DEPLOY_TOKEN -- only hosting
executors:
docker-executor:
docker:
- image: "cimg/node:12.14.1"
jobs:
build_site:
executor: docker-executor
working_directory: ~/Darryls-Personal-Site
steps:
- update
- build_deploy
version: 2.1
workflows:
build_site:
jobs:
- build_site:
filters:
branches:
only: master
Steps that I have already completed from other questions:
Used firebase login:ci to obtain refresh token and placed into an environment variable within my CircleCI project environment
Used npm install --save-dev firebase-tools
I think the problem is that you run all your npm commands with sudo except the firebase deploy command.
You should definitely run everything with the current user and not the superuser.
You will see in official tutorials that nothing is run with sudo except for very specific cases.
Also, instead of doing this ./node_modules/.bin/firebase deploy you could use npx run firebase deploy which first look in the local node_modules then in the global ones.
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
Can anyone recommend a good setup script to deploy to Modulus after passing tests?
Right now I'm using:
nvm install 0.10.28
nvm use 0.10.28
curl -o meteor_install_script.sh https://install.meteor.com/
chmod +x meteor_install_script.sh
sed -i "s/type sudo >\/dev\/null 2>&1/\ false /g" meteor_install_script.sh
./meteor_install_script.sh
export PATH=$PATH:~/.meteor/
meteor --version
Which is basically what I've managed to copy + paste around the interwebz and I have no idea what I'm doing.
Finally my test pipeline is:
meteor --test
The output from CodeShip logs:
I20150515-13:34:16.005(0)? [velocity] mocha is starting a mirror at http://localhost:44995/.
I20150515-13:34:16.006(0)? [velocity] This takes a few minutes the first time.
I20150515-13:34:16.006(0)? [velocity] You can see the mirror logs at: tail -f /home/rof/src/bitbucket.org/atlasshrugs/garden/.meteor/local/log/mocha.log
PASSED mocha : Server initialization => should have a Meteor version defined
As soon as it gets to the client-side tests, it hangs for ever and fails to build.
Any suggestions?
According to the Velocity readme you should use this command: meteor --test --release velocity:METEOR#1.1.0.3_1. I did manage to get it work using the following setup commands:
nvm install 0.10.30
nvm use 0.10.30
curl -o meteor_install_script.sh https://install.meteor.com/
chmod +x meteor_install_script.sh
sed -i "s/type sudo >\/dev\/null 2>&1/\ false
/g"meteor_install_script.sh
./meteor_install_script.sh
export PATH=$PATH:~/.meteor/
meteor --version
and this test command (replacing the with the path to the Meteor app directory. In this case sanjo:jasmine is required, but if you use another tester, you might need to add the related package. The velocity:html-reporter package is overkill for this purpose, but it does works, the console reporter should be enough, but I didn't test it):
cd ~/src/bitbucket.org/<path>/ &&
meteor add sanjo:jasmine velocity:html-reporter &&
meteor --test --release velocity:METEOR#1.1.0.3_1
I'm trying to configure a CI infrastructure at Codeship. My local meteor --test command works like charm, but I'm getting a weird error at Codeship.
Local:
I20141208-12:29:42.602(2)? Started
I20141208-12:29:42.602(2)? .
I20141208-12:29:42.603(2)?
I20141208-12:29:42.603(2)? 1 spec, 0 failures
I20141208-12:29:42.603(2)? Finished in 0.014 seconds
PASSED jasmine-server-unit : Job => Job should be created with title, description, location and isRemote
Codeship:
=> Started proxy.
=> Started MongoDB.
=> Errors prevented startup:
While Building the application:
node_modules/velocity-cli/velocity-cli.js:1:15: Unexpected token ILLEGAL
=> Your application has errors. Waiting for file change.
Setup commands:
curl -o meteor_install_script.sh https://install.meteor.com/
chmod +x meteor_install_script.sh
sed -i "s/type sudo >\/dev\/null 2>&1/\ false /g" meteor_install_script.sh
./meteor_install_script.sh
Test commands:
meteor --test
Ahoy,
velocity-cli needs to be install globally. Could you add the following command to your setup steps before you call the meteor executable?
npm install -g velocity-cli
Disclaimer: I'm working for Codeship
did you try
meteor run --test
command? This is what velocity-cli creators are telling to do now.
I got it working by changing the setup commands from the OP to the following :
curl -o meteor_install_script.sh https://install.meteor.com/
chmod +x meteor_install_script.sh
sed -i "s/type sudo >\/dev\/null 2>&1/\ false /g" meteor_install_script.sh
./meteor_install_script.sh
export PATH=$HOME/.meteor:$PATH
npm install -g velocity-cli
Also, for what it's worth I am using cucumber instead of jasmine and this still applies.