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. ;)
Related
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
I'm playing around with Yarn 2, and I want to do something like this.
I have a monorepo of the structure:
/
packages/
shared-ts/
package.json
src/
lib*/
app-ts/
package.json
src/
lib*/
app-js/
package.json
src/
lib*/
where lib* denotes that the folder is gitignored, but is where the compiled code will live.
In this example, I have a dependency library shared-ts that is used by two apps, app-ts and app-js.
The conventional approach
The conventional approach to configuring a monorepo like this, is that in shared-ts I would have a package.json like:
"main": "lib/index.js"
"scripts" : {
"build": "tsc"
}
Where the build script will build index.js and index.d.ts into the lib folder.
When both app-ts and app-js then resolve the package, they look in the lib folder and find the index.js and in app-ts's case - the index.d.ts.
This works fine, except that the developers need to remember to run the build script if they have made changes to shared-ts in order for the changes to propagate across.
Where this could potentially become problematic is where there are many layers of dependencies.
Attempted work around 1 - point main to src/index.ts.
I can change shared-ts package.json to
"main": "src/index.ts"
"scripts" : {
"build": "tsc"
}
This generally won't work, a plain node process won't be able to parse the syntax in the .ts file (eg. the import keyword).
Potential workaround - publishConfig
So something I'm considering, but haven't tried yet is, using the publishConfig
fields in the package.json
This field contains various settings that are only taken into consideration when a package is generated from your local sources (either through yarn pack or one of the publish commands like yarn npm publish).
"main": "src/index.ts",
"publishConfig": {
"main": "lib/index.js"
}
The idea being that:
When you publish a package to npm, lib/index.js will be used as main. 👍 code is ready for consumption, no compilation required.
If being used directly in the monorepo src/index.ts will be used as main. 😕 This kind of works as if you were running app-ts with ts-node for example.
However, where this starts breaking down is:
Running app-js in a development environment (where you don't have any additional syntax parsing set up).
Practical current best solution
My current best solution is to 'just give up on this 'no compile' aspiration' - if a developer makes changes to some code, they need to re-run build for the changes to propagate across.
How about using this?:
import someValue from 'some-package/src/index';
I can do this in my monorepo like the image below
I believe using nx will be good choice here. While it won't help you run the uncompiled code, it has pretty good features. In particular, you can automatically run the affected:apps on certain changes. For example, if you have a start command, it will run the start command for all the affected apps.
I wanted the same thing but had to compromise on the "Automatic compilation on changes" option in my JetBrains IDE.
It allows me to debug with ts-node as well as run the code using the native node binary.
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.
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.
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.