I use Renovate to keep my dependencies up-to-date. However there are some dependencies that I want to exclude from automatic updates, i.e. I don't want Renovate to update them, ever.
One such dependency is Postgres, which is specified in docker-compose.yml like so:
services:
db:
image: postgres:11
Currently, Renovate is creating PRs that would change the 11 to 15. Is there a configuration option in Renovate that allows me to exclude this dependency from Renovate?
Related
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 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.
How to disable any optional feature in jhipster such as "Kafka" rather than regenerating another Jhipster app from scratch?
Edit the .yo-rc.json file in your project, commit it, delete src folder and run jhipster --with-entities.
Of course, if you already have added custom code, you may want to do this in a git branch and use adequate git merging strategy like git merge -s recursive -Xours <branch name> to keep your changes
Scenario:
We have a dependency structure such that there are 3 separate private repos:
libA
serviceA
serviceB
Both services require the use of libA (a shared, private library). In addition, serviceA has serviceB in the devDependencies for tests. a visual representation of the tree is shown below.
serviceA ---> libA
|--> serviceB ---> libA
All private repos are listed in the package.json to be cloned using SSH
git+ssh://git#github.com:{ORG}/{repo}.git
Question:
We have many scenarios where we want to change code (by creating branch and PR) in all 3 repos at the same time. In order for the tests to pass, all repos must be cloned using the specified branch, and if not, use the default. When running tests locally, we will sym-link the deps manually, or use npm link.
When running the tests for serviceA in CI, it would be possible to run a pre-build script to edit the package.json with the new branches (for libA and serviceB). Unfortunately, that doesn't fix the fact that the deps for serviceB need to be edited so that when it installs libA it uses the correct, new branch.
What would be the best way to go about this?
I'm used to deploy code depending on Composer (PHP's NPM cousing), that sports .json and .lock files. The first one describes the package and your version constraints, and the second one lists exactly what was installed. Always there's a lock file and you run composer install you're sure to receive the same set of packages; running composer update will re-read the json file, install new versions, and update the lock file.
That's awesome for production deployment, since you don't need to checkout your dependencies to your versioning system and you're sure to have the exact same set of dependencies in production as you have in development.
My question is: how to best automate deployment of NPM-dependent code? Is it possible to achieve a method similar to Composer? I've noticed that npm install only installs what's first available in the package.json file. After the first run, i.e. if you change a version constraint you must manually npm update that package - and that would render automate deployment useless, as there's no way to check in to versioning "update this package here to a new version"...
npm shrinkwrap is a analog of composer.lock file. It will generate a npm-shrinkwrap.json, that have all deps with version in it, so you can use it to deploy to production env. Also you can try a various libs from npm to lock versions or search for updates of it without changing packages.json.