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.
Related
I am currently in the process of implementing a CI script for a node project. On of the steps involved in this process is to be able to get the project's version from the package.json file and setting it as an env variable (used subsequently for various operations).
What I have tried so far is creating the following job:
version:get-version:
stage: version
script: |
npm pkg get version
version=$(npm pkg get version)
echo "Current version: $version"
echo "PROJECT_VERSION=$version" >> .env
artifacts:
reports:
dotenv: .env
rules:
- if: $CI_COMMIT_BRANCH == "master"
- if: '$CI_COMMIT_BRANCH =~ /^feat.*/'
- if: $CI_COMMIT_TAG
The problem is that when I run the individual commands using the same docker image my CI is using (node:lts-alpine3.16) everything works fine. However when this job runs, it fails with the following error:
Created fresh repository.
18Checking out a3ac42fd as feat/SIS-540-More-CI-Changes...
19Skipping Git submodules setup
20
Executing "step_script" stage of the job script
00:00
21$ npm pkg get version # collapsed multi-line command
22
Uploading artifacts for failed job
00:01
23Uploading artifacts...
24WARNING: .env: no matching files. Ensure that the artifact path is relative to the working directory
25ERROR: No files to upload
26
Cleaning up project directory and file based variables
00:00
27ERROR: Job failed: command terminated with exit code 243
What is even more interesting is that, sometimes the same job would succeed with no problems (at least printing out the version using npm pkg get version). I am honestly stuck and I have no idea how to troubleshoot this or resolve it.
Any hints or ideas are more than welcome.
I have a mono repo that I manage with lerna and has the following structure:
root:
- packages:
- package_a
- package_b
- package_c
In the code I have package_c as a dependency in package_a, so in package_a's package.json file I have
dependencies: {
package_c: "1.0.0"
}
However, if I want to push a change to all packages, the version update, and my package_a points to an old version of package_c.
Is there a way to make sure package_a users the latest version I push of package_c? I tried using the latest tag but for some reason it did not work.
I saw that projects like #wdio use a link script but can't figure out how it works.
Thank you in advance.
I am fairly new to GitLab CI and I've been trying different approaches to use the node_modules directory in my entire pipeline. From what I've read in the official docs, cache and artifacts seem to be valid approaches to pass on files between jobs:
cache is used to specify a list of files and directories which should
be cached between jobs. You can only use paths that are within the
project workspace.
However, my issue with the caching method is that the node_modules would be persisted between pipelines by default:
cache can be set globally and per-job.
from GitLab 9.0, caching is enabled and shared between pipelines and jobs by default.
I do not want to persist the node_modules between pipelines. What I actually want is to trigger a fresh install with npm in my setup stage and then allow all further jobs in the pipeline to use these modules. Hence, I started using artifacts instead of cache, which is described similarly:
artifacts is used to specify a list of files and directories which
should be attached to the job after success. [...]
The artifacts will be sent to GitLab after the job finishes
successfully and will be available for download in the GitLab UI.
The dependency feature should be used in conjunction with artifacts
and allows you to define the artifacts to pass between different jobs.
The artifact-dependency method seems to be usable in my case. However, both cache and artifacts are extremely inefficient and slow. The node_modules are installed and usable, but the entire directory then gets uploaded somewhere and is re-downloaded between each job. (I would really love to know what happens here... Where do the modules go?)
Is there a better approach to run npm install only once at the beginning of the pipeline and then keep the node_modules in the pipeline during its entire runtime? I do not want to keep the node_modules after all jobs are finished so they don't need to be uploaded or downloaded anywhere.
Sample pipeline configuration file to reproduce the behavior:
image: node:lts
stages:
- setup
- build
- test
node:
stage: setup
script:
- npm install
artifacts:
paths:
- node_modules/
build:
stage: build
script:
- npm run build
dependencies:
- node
test:
stage: test
script:
- npm run lint
- npm run test
dependencies:
- node
Where do the modules go?
By default artifacts are saved on the main gitlab machine:
/var/opt/gitlab/gitlab-rails/shared/artifacts
Is there a better approach to run npm install only once at the beginning of the pipeline and then keep the node_modules in the pipeline during its entire runtime?
There are some options that you can try:
Merge setup and build stages to one stage.
Local npm cache on builder machines. Faster npm install times. Or use private npm proxy registry (for example - Nexus/Artifactory)
Check if gitlab main machine and the builders are in the same network so the upload/download will be faster
Consider packaging your build in docker. You will get reusable docker images between your gitlab stages. (Of course that there is an overhead of uploading the images to docker registry)
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'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. ;)