I'm setting up Bitbucket Pipelines to build a project using node 14.21.2, but it is being run with an image using node 4.2.1.
Here is the configuration I am using and the build output.
Pipelines config
definitions:
services:
npmbuild:
image: node:14.21.2
variables:
NPM_TOKEN: $NPM_TOKEN
pipelines:
default:
- step:
name: Build Production
services:
- npmbuild
script:
- node -v
Output
+ node -v
v4.2.1
N/A: version "v14.21.2" is not yet installed
How can I change this to use the correct version of node?
UPDATE: I have a workaround where I just specify the image at the root level, but my question still remains as to why setting the image at the step level didn't work as expected.
Related
With AzureDevOps I get the following error since yesterday, before that everything worked fine for months:
The current Compose file version is not compatible with your engine version. Please
upgrade your Compose file to a more recent version, or set a COMPOSE_API_VERSION in your
environment.
In Azure-DevOps I use in the pipeline:
- task: DockerCompose#0
displayName: Run services
inputs:
containerregistrytype: 'Container Registry'
dockerComposeFile: 'build/docker/docker-compose.yml'
dockerComposeFileArgs: 'DOCKER_BUILD_SOURCE=$(System.DefaultWorkingDirectory)'
action: 'Run services'
buildImages: false
My docker-compose (docker-compose.yml) file looks like this (details changed):
version: '3.0'
services:
sqlserver:
image: willh/mssql-server-windows-developer:latest
container_name: sqlserver
shm_size: 4gb
ports:
- "1433:1433"
environment:
- ACCEPT_EULA=Y
- SA_PASSWORD=a(!)Passcode
I realized the updated microsoft build agent Image:
from: https://github.com/actions/runner-images/blob/win22/20230129.1/images/win/Windows2022-Readme.md
which worked well
containing:
Docker 20.10.23
Docker Compose v1 1.29.2
Docker Compose v2 2.15.1
Docker-wincred 0.7.0
to: https://github.com/actions/runner-images/blob/win22/20230206.1/images/win/Windows2022-Readme.md
which does not work
containing:
Docker 23.0.0
Docker Compose v1 1.29.2
Docker Compose v2 2.15.1
Docker-wincred 0.7.0
But i do not see how I can get it to work again.
Which COMPOSE_API_VERSION would I have to set? The same as I have in the docker-compose.yml file?
The error message you are receiving indicates that the version of Docker Compose being used is not compatible with the version specified in your Docker Compose file (docker-compose.yml). The version specified in your Docker Compose file is 3.0, but the version of Docker Compose installed on the updated build agent image is 2.15.1.
To resolve this issue, you can either upgrade the Docker Compose file to a version that is compatible with the installed version of Docker Compose, or you can set the COMPOSE_API_VERSION environment variable to the version specified in the Docker Compose file.
In your case, you could set the COMPOSE_API_VERSION environment variable to 3.0:
env:
COMPOSE_API_VERSION: '3.0'
and add this environment variable to the Azure DevOps pipeline task:
- task: DockerCompose#0
displayName: Run services
inputs:
containerregistrytype: 'Container Registry'
dockerComposeFile: 'build/docker/docker-compose.yml'
dockerComposeFileArgs: 'DOCKER_BUILD_SOURCE=$(System.DefaultWorkingDirectory)'
action: 'Run services'
buildImages: false
env:
COMPOSE_API_VERSION: '3.0'
This should allow the pipeline task to use the correct version of Docker Compose and avoid the compatibility error.
I'm setting up the CI for an existing Express server project that lives in my repo's backend/core folder. Starting with just basic setup and linting. I was able to get npm install and linting to work but I wanted to cache the dependencies so that it wouldn't take 4 minutes to load for each push.
I used the caching scheme they describe here but it still seemed to run the full install each time. Or if it was using cached dependencies, it installed grpc each time which took a while. Any ideas what I can do?
My config.yml for reference:
# Use the latest 2.1 version of CircleCI pipeline process engine. See: https://circleci.com/docs/2.0/configuration-reference
# default executors
executors:
core-executor:
docker:
- image: 'cimg/base:stable'
commands:
init_env:
description: initialize environment
steps:
- checkout
- node/install
- restore_cache:
keys:
# when lock file changes, use increasingly general patterns to restore cache
- node-v1-{{ .Branch }}-{{ checksum "backend/core/package-lock.json" }}
- node-v1-{{ .Branch }}-
- node-v1-
- run: npm --prefix ./backend/core install
- save_cache:
paths:
- ~/backend/core/usr/local/lib/node_modules # location depends on npm version
key: node-v1-{{ .Branch }}-{{ checksum "backend/core/package-lock.json" }}
jobs:
install-node:
executor: core-executor
steps:
- checkout
- node/install
- run: node --version
- run: pwd
- run: ls -A
- run: npm --prefix ./backend/core install
lint:
executor: core-executor
steps:
- init_env
- run: pwd
- run: ls -A
- run: ls backend
- run: ls backend/core -A
- run: npm --prefix ./backend/core run lint
orbs:
node: circleci/node#4.1.0
version: 2.1
workflows:
test_my_app:
jobs:
#- install-node
- lint
#requires:
#- install-node
I think the best thing to do is to use npm ci which is faster. Best explanation of this is here: https://stackoverflow.com/a/53325242/4410223. Even though it will reinstall every time, it is consistent so better than caching. Although when using this, I am unsure what the point of continuing to use cache in your pipeline is, but caching still seems to be recommended with npm ci.
However, the best way to do this is to just use the node orb you already have in your config. A single step of - node/install-packages will do all that work for you. You will be able to replace it with your restore_cache, npm install and save_cache steps. You can even see all the steps it does here: https://circleci.com/developer/orbs/orb/circleci/node#commands-install-packages. Just open the command source and look at the steps on line 71.
I have installed gitlab runner in my server and binded with the gitlab repo and pipelines.
here's my gitlab-ci.yml
image:
name: node:14.9.0
stages:
- install
- deploy
install for production:
image: node:14.9.0
stage: install
tags:
- mytag
only:
- master
script:
- node -v
- /home/gitlab-runner/.nvm/versions/node/v14.9.0/bin/npm i -s
deploy to production server:
image: node:14.9.0
stage: deploy
only:
- master
script:
- cp -r * /the/folder/backend/
- cd /the/folder/backend/
- /home/gitlab-runner/.nvm/versions/node/v14.9.0/bin/npm run migrate
- node_modules/pm2/bin/pm2 reload all --update-env -- DB_OPERATOR_USERNAME=$DB_OPERATOR_USERNAME DB_OPERATOR_EMAIL=$DB_OPERATOR_EMAIL DB_OPERATOR_PASSWORD=$DB_OPERATOR_PASSWORD DB_ADMIN_USERNAME=$DB_ADMIN_USERNAME DB_ADMIN_EMAIL=$DB_ADMIN_EMAIL DB_ADMIN_PASSWORD=$DB_ADMIN_PASSWORD DB_USERNAME=$DB_USERNAME DB_DATABASE=$DB_DATABASE DB_PASSWORD=$DB_PASSWORD
after pushing the master branch and let the pipeline run, it's not loading the 14.9.0 node version.
Checking out b795f45a as master...
Removing node_modules/
Skipping Git submodules setup
Executing "step_script" stage of the job script
$ node -v
v8.10.0
$ /home/gitlab-runner/.nvm/versions/node/v14.9.0/bin/npm i -s
if I ssh into my server, the node version that nvm loads (the default one) is the 14.9.0
I have 2 runners in this machine. The first one for the frontend (and it loads the correct default version of node, which is 14.9.0) and the second one for the backend that has the above problem. The node versions are the same. I don't have docker at the moment and the node -v command inside sudo su gitlab-runner user shows 14.9.0
Why the gitlab runner is loading the 8.10.0 version? how can I set it to 14.9.0?
Thanks in advance
Try to run the docker image inside the gitlab runner and check the global version of node, the problem does not seem to be the runner.
I'm trying to restore from Azure Artefacts in CircleCI. I've been trying to piece together bits and pieces from artifacts-credprovider, including the Docker image example. My circle CI config looks like this:
version: 2.1
jobs:
build:
docker:
- image: mcr.microsoft.com/dotnet/core/sdk:3.1
working_directory: ~/repo
steps:
- checkout
- run:
name: Install Artifacts Credprov
command: |
wget -qO- https://raw.githubusercontent.com/Microsoft/artifacts-credprovider/master/helpers/installcredprovider.sh | bash
- run:
name: Restore Packages
command: dotnet restore
- run:
name: Build
command: dotnet build
workflows:
main:
jobs:
- build
In the CircleCI Project I've also set the following env vars:
DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0
NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED-true
VSS_NUGET_EXTERNAL_FEED_ENDPOINTS={"endpointCredentials": [{"endpoint":"https://pkgs.dev.azure.com/paulgrenyer0243/_packaging/paulgrenyer0243/nuget/v3/index.json", "username":"...", "password":"..."}]}
and when restoring this is the error I get:
#!/bin/bash -eo pipefail
dotnet restore
/usr/share/dotnet/sdk/3.1.201/NuGet.targets(124,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/paulgrenyer0243/_packaging/paulgrenyer0243/nuget/v3/index.json. [/root/repo/NugetClient.csproj]
/usr/share/dotnet/sdk/3.1.201/NuGet.targets(124,5): error : Response status code does not indicate success: 401 (Unauthorized). [/root/repo/NugetClient.csproj]
Exited with code exit status 1
I'm assuming that either the env vars aren't being picked up, the env vars have the wrong values or I'm trying the wrong approach.
Does anyone have this working or can see what I'm doing wrong?
Restoring from Azure Artefacts in CircleCI
I agree with you. The dotnet restore task did not get the env vars from the CircleCI Project.
You could try to set the environment variable in a container, like:
version: 2.1
jobs:
build:
docker:
- image: mcr.microsoft.com/dotnet/core/sdk:3.1
environment:
VSS_NUGET_EXTERNAL_FEED_ENDPOINTS: {"endpointCredentials": [{"endpoint":"https://pkgs.dev.azure.com/XXX/_packaging/XXX/nuget/v3/index.json", "username":"...", "password":"..."}]}
Then specify source during restoring package:
- run:
name: Restore Packages
command: dotnet restore -s "https://pkgs.dev.azure.com/XXX/_packaging/XXX/nuget/v3/index.json" -s "https://api.nuget.org/v3/index.json"
You could check this document and this thread for some more details.
Hope this helps.
I have a repository that serves as a driver for kubernetes and docker, built using nodejs.
I have created several test cases for this repo to work on docker and kubernetes, and they all passed locally.
The only thing I don't know how to do is to set up kubernetes on the travis YML. Surprisingly, I can't find any decent examples anywhere. Below is the YML file I have, and between <> is the gap I need help to fill.
sudo: required
language: node_js
node_js: 6.9.5
services:
- docker
- <kubernetes>
branches:
only:
- staging
- master
addons:
hosts:
- localhost
- dev-controller
before_script:
- npm install -g grunt-cli
- docker pull soajsorg/soajs
- <pull the soajsorg/soajs image and load it to kubernetes>
script:
- grunt coverage
You could try to install minikube: http://github.com/kubernetes/minikube if you need it running on TravisCI otherwise I would suggest connecting to a self-managed Kubernetes cluster or using Google's cli/sdk to launch a small GKE cluster and use that for testing