Using Travis-CI for Node.js project - node.js

I'm trying to set up travis-ci for my node.js project hosted on github. For some reason travis keeps using ruby worker for building/testing the project.
My .travis.yml looks like:
language: node_js
node_js:
- 0.6
script:
- "make test"
What am I missing?

OK got it.
The .travis.yml file must not contain 'tab' characters. Instead I have replaced them with spaces.

Related

The cypress npm package is installed, but the Cypress binary is missing (newbie)

I see many instances of this question but nothing that helps me. Apologies if this question gets boring.
I am just starting out with node.js, Cypress and GitLab Pipelines.
I've cobbled together something that has a simple web app, a few simple tests.
It ran fine the first time but, on subsequent commits, it fails at the 'Cypress Tests' step with: The cypress npm package is installed, but the Cypress binary is missing.
There's a lot more to the log but I don't know what is relevant.
Here is my yml file
cypress tests:
stage: test
image: cypress/browsers:node14.17.0-chrome91-ff89
cache:
key: package-lock.json
paths:
- node_modules
before_script:
- npm install
- npm run dev &
- ./node_modules/.bin/wait-on http://localhost:3000
script:
- npm run cypress
only:
- merge_requests
- master
Could you please help with anything that looks like it might be the culprit?
Or at least help me understand how to read the situation better?
I tried reading the docs as much as I can, I just can't see the right way.
I'm also a beginner but I'm trying to answer. First you can add "cypress:open" : "cypress open" to the file package.json. For more details you can watch this video

All mocha tests pass locally but fail on Travis CI

I am building an api, everything works locally but on Travis-CI, the test fails. For the first time I was getting "mocha: permission denied". I deleted node_modules in my repository so that the Travis can install all dependacies with "npm install". And then I start getting this: enter image description here
Thanks for your help!
As you can see in picture that you have supplied on remote machine node --version is v0.10.48. In that version Node.js is not supporting ES6 syntax.
In your .travis.yml file you need to set node_js version on which you want to run tests like this:
node_js:
- 10
- 9
- 8
With this part your tests will be run on three version of Node.js. More information what you can put in .travis.yml you can find in official documentation.

What could cause eslint-plugin-prettier to report error on CircleCI but be silent locally?

I have to migrate from CircleCI 1.0 to 2.0. After I have changed the old configuration to the new one, build failed because of eslint-plugin-prettier reported prettier spacing violations.
MyProject - is my GitHub repo and it contains a folder client which has all front-end code which I want to build on CI. In client folder there are
.eslintrc.json
...
"extends": ["airbnb", "prettier"],
"plugins": ["prettier"],
...
.prettierrc
{
"tabWidth": 4,
"trailingComma": "all",
"singleQuote": true
}
.gitattributes (I work on Windows 10) with the following code:
*.js text eol=crlf
*.jsx text eol=crlf
and of course package.json
New CircleCI configuration:
version: 2
jobs:
build:
working_directory: ~/MyProject
docker:
- image: circleci/node:6.14.3-jessie-browsers
steps:
- checkout
- run:
name: Install Packages
command: npm install
working_directory: client
- run:
name: Test
command: npm run validate
working_directory: client
Old CircleCI configuration:
## Customize dependencies
machine:
node:
version: 6.1.0
# Remove cache before new build. It takes much time
# but fixing a build which is broken long time ago (and not detected because of cache)
# is even more time consuming
dependencies:
post:
- rm -r ~/.npm
## Customize test commands
test:
override:
- npm run validate
general:
build_dir: client
The build fails due to linting problems (all are about the number of spaces):
So, what could cause these errors? I am out of ideas here. I first thought it might be because .prettierrc was not found. However, when I deleted it for an experiment and run locally I got errors in all files in total more than 1000. While on CI with .prettierrc in place there are were only 188 in few files.
I have finally figured it out.
My package.json file contained the following dependency on the Prettier:
"prettier": "^1.11.1".
I had to learn hard way the meaning of this little symbol ^. It allows installing any version of Prettier which is compatible with 1.11.1. In my case on CircleCI 2.0 it installed 1.14.2 which adds new features to Prettier.
I believe it did not break on CircleCI version 1.0 and locally because of cached node_modules which contained earlier Prettier versions compatible with 1.11.1
Here is nice video about semantic versioning.
In my case the problem was with the pattern.
The eslint src/**/*.{ts,tsx} command failed in GitLab CI, but not on local.
When I changed it to eslint src it failed both on local and CI.

Why is my .travis.yml file being ignored?

Here is my .travis.yml file:
language: node_js
node_js:
- "6.10"
- "6"
cache:
directories:
- node_modules
(It is also available on Github.)
Here is my build log on Travis, showing the wrong Node version:
And here is the versionless config for the same build:
Finally, here is the caching report for my build:
I have tried changing my .travis.yml file in numerous ways, including:
other version strings,
different indentations and line ending combinations,
with and without cache, etc.,
but nothing I do seems to have any effect.
I have enabled "Build only if .travis.yml is present", so apparently it is finding the file itself, just not what's in it. What am I missing?
It turns out there was hidden leading whitespace before my language key. A helpful Travis tech support specialist removed the whitespace and solved my problem.
I had the same problem, but the solution was, that I had a foder named .travis/ in the root directory. I had to rename it to something else and then travis notived the .travis.yml file again

Travis-CI with jasmine-node

I'm trying to get travis-ci to test my nodejs module with jasmine-node. When I run the tests from the commandline, they all pass, but for whatever reason, Travis always reports my build as failing. My .travis.yml looks like this:
language: node_js
node_js:
- 0.6
- 0.8
and my package.json looks like this:
"scripts": {
"test": "jasmine-node tests/*.spec.js"
}
I've tried adding a before_script to my travis.yml
language: node_js
node_js:
- 0.6
- 0.8
before_script:
- "sudo npm i -g jasmine-node"
Any ideas?
After spending some time with the travis-ci lint web app, it looks like it just came down to a matter of formatting in my .travis.yml file. My text editor was inserting tabs, where it appears that yaml requires you only use spaces. I also added quotes around everything for good measure.
It now looks like this, after making sure I was only using single spaces and newlines:
language: node_js
node_js:
- "0.6"
- "0.8"
before_script:
- "npm i -g jasmine-node"
Here is a repository with a working exemple of a travis build launching jasmine-node tests: https://github.com/yosethegame/yosethegame.
Note that the package.json declares the jasmine-node dependency that travis will install in its npm install phase.
I had a similar problem some time ago, I was using at the time jasmine-node -g and since it was a simple kata I thought there was no need for adding a package.json in the folder, but when I moved onto integrating that same project with travis-ci, I went through hell to be able to configure it.
With time I've learnt that it is better to keep things nice and tight and use your friendly package.json instead of global installations (There is a good post talking about it here for example: Why to avoid global test runners )
My advice would be for you to add jasmine-node to the package.json, something as short as this
{
"name" : "XXX",
"version" : "1.0.0",
"devDependencies" : {
"jasmine-node" : "latest"
},
"scripts" : {
"test" : "jasmine-node specs/*spec.js"
}
}
Will surely save you a headache and tons of configuring time not only with travis-ci integration, and it may as well save someone else's time in case someone wants to reuse what you've done. ;)

Resources