How to analyze image build that fails silently in CI tool? - bash

My Docker image is failing during build in GitLab CI and it fails silently without giving any errors to work with. I can build the image locally and no problem whatsoever so the problem is in CI environment. Something that is not obvious causes the build to fail. After doing some research about this I've learned the best thing to do to SSH into the CI server and "poke around" to find out what's happening. In particular I've learned that I can get a log of the last layer before the build fails to get insight into why it might be failing. However, GitLab doesn't support direct SSH connection into CI server. Supports only fixed SSH commands executed towards the server from the build environment (.gitlab-ci.yml) which isn't very helpful because I need to use SSH to access build layers of the image.
What are my other options as to how can I debug / analyze an image during build in CI ?
Any feedback much appreciated.
Dockerfile:
###########
# BUILDER #
###########
# base image
FROM node:11.12.0-alpine as builder
# set working directory
WORKDIR /usr/src/app
RUN apk add --no-cache --virtual .gyp python make g++
# install app dependencies
ENV PATH /usr/src/app/node_modules/.bin:$PATH
COPY package.json /usr/src/app/package.json
COPY package-lock.json /usr/src/app/package-lock.json
RUN npm install --no-optional
RUN npm install react-scripts#2.1.8 -g --silent --no-optional
# set environment variables
ARG REACT_APP_USERS_SERVICE_URL
ENV REACT_APP_USERS_SERVICE_URL $REACT_APP_USERS_SERVICE_URL
ARG NODE_ENV
ENV NODE_ENV $NODE_ENV
# create build
COPY . /usr/src/app
RUN npm run build
#########
# FINAL #
#########
# base image
FROM nginx:1.15.9-alpine
# update nginx conf
RUN rm -rf /etc/nginx/conf.d
COPY conf /etc/nginx
# copy static files
COPY --from=builder /usr/src/app/build /usr/share/nginx/html
# expose port
EXPOSE 80
# run nginx
CMD ["nginx", "-g", "daemon off;"]
.gitlab-ci.yml file:
...
...
after_script:
- bash ./docker-push.sh
- docker-compose down
docker-push.sh script that builds the image for pushing into ECR on AWS:
echo "building the client image ..."
docker -D build $CLIENT_REPO -t $CLIENT:$COMMIT -f Dockerfile-prod --build-arg REACT_APP_USERS_SERVICE_URL="" # this line is failing
if [ $? -ne 0 ]; then
echo "Failure. Exiting now..."
exit 1
fi
docker -D tag $CLIENT:$COMMIT $REPO/$CLIENT:$TAG
docker -D push $REPO/$CLIENT:$TAG
docker build $USERS_REPO -t $USERS:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $USERS:$COMMIT $REPO/$USERS:$TAG
docker push $REPO/$USERS:$TAG
docker build $USERS_DB_REPO -t $USERS_DB:$COMMIT -f Dockerfile
docker tag $USERS_DB:$COMMIT $REPO/$USERS_DB:$TAG
docker push $REPO/$USERS_DB:$TAG
docker build $SWAGGER_REPO -t $SWAGGER:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $SWAGGER:$COMMIT $REPO/$SWAGGER:$TAG
docker push $REPO/$SWAGGER:$TAG
job log from gitlab ci (relevant part only):
Login Succeeded
building the client image ...
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: .dockerignore"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile-prod"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile-stage"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: .dockerignore"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile-prod"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile"
time="2020-04-14T08:54:23Z" level=debug msg="Skipping excluded path: Dockerfile-stage"
Step 1/25 : FROM node:11.12.0-alpine as builder
---> 09084e4ff58d
Step 2/25 : WORKDIR /usr/src/app
---> Using cache
---> 9c6639a8a785
Step 3/25 : RUN apk add --no-cache --virtual .gyp python make g++
---> Using cache
---> 0d5320ee514b
Step 4/25 : ENV PATH /usr/src/app/node_modules/.bin:$PATH
---> Using cache
---> c041f8c64b34
Step 5/25 : COPY package.json /usr/src/app/package.json
---> 02d18d67a517
Step 6/25 : COPY package-lock.json /usr/src/app/package-lock.json
---> 2d94e8e8fb6c
Step 7/25 : RUN npm install --no-optional
---> Running in 59660215041e
> cypress#4.1.0 postinstall /usr/src/app/node_modules/cypress
> node index.js --exec install
Installing Cypress (version: 4.1.0)
[08:55:20] Downloading Cypress [started]
[08:55:20] Downloading Cypress 0% 0s [title changed]
[08:55:20] Downloading Cypress 2% 5s [title changed]
...
...
[08:55:39] Unzipping Cypress 9% 167s [title changed]
[08:55:39] Unzipping Cypress 100% 0s [title changed]
[08:55:39] Unzipped Cypress [title changed]
[08:55:39] Unzipped Cypress [completed]
[08:55:39] Finishing Installation [started]
[08:55:40] Finished Installation /root/.cache/Cypress/4.1.0 [title changed]
[08:55:40] Finished Installation /root/.cache/Cypress/4.1.0 [completed]
You can now open Cypress by running: node_modules/.bin/cypress open
https://on.cypress.io/installing-cypress
added 2034 packages from 768 contributors and audited 38602 packages in 77.201s
found 1073 vulnerabilities (1058 low, 14 moderate, 1 high)
run `npm audit fix` to fix them, or `npm audit` for details
Saving cache
00:02
Uploading artifacts for successful job
00:02
Job succeeded

Related

gitlab runner with 2 workers: 1st worker (BE) fine, 2nd worker (FE) uses docker instead of shell

Firstly I set up 1 worker for 1 job. Deploying my backend for the API.
I'm using "shell" as the executer. The .toml file is this structure:
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "Gitlab Runner Josere Backend"
url = "https://gitlab.com/"
token = "sOmEtOkeN1G0Tfr0mGitlab"
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
[some mumbo jumbo about caching.. does it matter?]
With some struggle I got that to work fine with this .gitlab-ci.yml:
deploy-production:
stage: deploy
variables:
GIT_STRATEGY: clone
script:
- cd ./lumen/
- composer install
- sudo cp -r $CI_PROJECT_DIR/lumen/. /home/josere/public_html/api/
- sudo cp /home/josere/env/.env /home/josere/public_html/api
This is the execution output of the runner:
Running with gitlab-runner 15.2.1 (32fc1585)
on Gitlab Runner Josere backend 9JxGrMLz
Preparing the "shell" executor
00:00
Using Shell executor...
Preparing environment
00:00
Running on ####[my server]#####...
Getting source from Git repository
00:03
Fetching changes with git depth set to 50...
Initialized empty Git repository in /home/gitlab-runner/builds/9JxGrMLz/0/paspalas/josere/.git/
Created fresh repository.
... etc ...
In my frontend repo in Gitlab I went to the same runners settings. I can't really install a runner (its allready running I guess) but I can copy the token that is shown there.
Then I changed my .toml file according to this doc from gitlab (https://docs.gitlab.com/runner/fleet_scaling/):
concurrent = 2
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "Gitlab Runner Josere Backend"
url = "https://gitlab.com/"
token = "sOmEtOkeN1G0Tfr0mGitlab"
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
[some mumbo jumbo about caching.. does it matter?]
[[runners]]
name = "Gitlab Runner Josere Frontend"
url = "https://gitlab.com/"
token = "TheOtherTokenThatIgotFromFrontendRepo!"
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
[some mumbo jumbo about caching.. does it matter?]
notice I do keep the executor on "shell".
this is the script for .gitlab-ci.yml that goes in the root of the frontend repo:
deploy-production:
stage: deploy
variables:
GIT_STRATEGY: clone
script:
- npm install
- npm run build
- sudo cp -r $CI_PROJECT_DIR/public/. /home/josere/public_html/
But when I commit my frontend and check the (failing) log for the worker it writes this:
Running with gitlab-runner 15.4.0~beta.5.gdefc7017 (defc7017)
on green-1.shared.runners-manager.gitlab.com/default JLgUopmM
Preparing the "docker+machine" executor
00:06
Using Docker executor with image ruby:2.5 ...
Pulling docker image ruby:2.5 ...
Using docker image sha256:27d###mumbojumbo###2383b for ruby:2.5 with digest ruby#sha256:ecc3###mumbojumbo###444b ...
Preparing environment
00:00
Running on runner-jlguopmm-project-39467125-concurrent-0 via runner-jlguopmm-shared-1665674167-6adf45bf...
Getting source from Git repository
00:02
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/paspalas/josere-frontend/.git/
Created fresh repository.
Checking out c39e641c as materialui...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:01
Using docker image sha256:27d###mumbojumbo###3b for ruby:2.5 with digest ruby#sha256:ecc3e###mumbojumbo####44b ...
$ sudo npm install
/bin/bash: line 126: sudo: command not found
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1
clearly it seems multiple things go wrong, to start with: why is it using docker while I explicitly tell it to be "shell"?
I fixed the issue. Even though the docs of GitLab differentiates between "runner" and "job", the gitlab-runner calls these "registrations" of a "runner". I did the (extra) registeration like so:
- gitlab-runner register
[filling in info]
- nano /etc/gitlab-runner/config.toml
[check if you have the additional runner]
- gitlab-runner run
[according to gitlab-runner help this is to fire up multiple runners]
- gitlab-runner list
[ now you can check if all "runners" (jobs) are running]

Gitlab runner cache miss file after stage complete

Summary
My gitlab-ci.yml has 3 stage for deploy an application to okd pod
Application running spring boot on tomcat:8
Sometimes, the cache.zip is not update after stage complete so that the next step can't run correctly
Steps to reproduce
My gitlab-ci run the following stage
Stage 1: run test compile ---> OK
Stage 2: package war file as output for deploy ---> Gitlab-ci log show success but the cache.zip has not war file (just sometimes cache.zip not have war file, sometimes it run correctly)
Stage 3: Deploy war file to pod ---> Because of war file not exists in cache.zip, script error -> failed
.gitlab-ci.yml
image: openshift/origin-cli
stages:
- build
- test
- staging
cache:
paths:
- .m2/repository
- target
- artifact
validate:jdk8:
stage: build
script:
- 'mvn test-compile'
only:
- master
image: maven:3.3.9-jdk-8
verify:jdk8:
stage: test
script:
- 'mvn verify'
- 'mvn package' # =====> this command generate war file
only:
- master
image: maven:3.3.9-jdk-8
staging:
script:
- "mkdir -p artifact"
- "cp ./target/*.war ./artifact/" # ======> Sometimes error at this line because of previous step not add war file into cache
- "oc start-build $APP"
- "rm -rf ./target/* && rm -rf ./artifact/*" # Remove war & class file, only cache m2 lib
stage: staging
variables:
APP: $CI_PROJECT_NAME
environment:
name: staging
url: http://$CI_PROJECT_NAME-staging.$OPENSHIFT_DOMAIN
only:
- master
Actual behavior
Sometimes cache not have war file after test stage complete (is this depends on war file size?)
Expected behavior
War file update into cache after test stage for staging stage deploy
Relevant logs and/or screenshots
ScreenShot
job log
Running with gitlab-runner 13.7.0 (943fc252)
on gitlab-runner-node1 y6awygsj
Preparing the "docker" executor
00:01
Using Docker executor with image openshift/origin-cli ...
Using locally found image version due to if-not-present pull policy
Using docker image sha256:7ebb6be01117a50344d63f77c385a13302afecd33480b97c36a518d4f5ebc25a for openshift/origin-cli with digest docker.io/openshift/origin-cli#sha256:509e052d0f2d531b666b7da9fa49c5558c76ce5d286456f0859c0a49b16d6bf2 ...
Preparing environment
00:00
Running on runner-y6awygsj-project-489-concurrent-0 via gitlab.runner.node1...
Getting source from Git repository
00:01
Fetching changes...
Reinitialized existing Git repository in /builds/my-project/.git/
Checking out b4c97428 as master...
Removing .m2/
Removing artifact/
Removing target/
Skipping Git submodules setup
Restoring cache
00:05
Checking cache for default-23...
No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted.
Successfully extracted cache
Executing "step_script" stage of the job script
00:01
$ mkdir -p artifact
$ cp ./target/*.war ./artifact/
cp: cannot stat './target/*.war': No such file or directory
Cleaning up file based variables
00:00
ERROR: Job failed: exit code 1
Environment description
config.toml
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "gitlab-runner-node1"
url = "https://gitlab.mycompany.vn/"
token = "y6awygsj9zks18nU6PDt"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
dns = ["192.168.100.1"]
tls_verify = false
image = "alpine:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/mnt/nfs/nfsshare-gitlab/cache:/cache"]
shm_size = 0
pull_policy = "if-not-present"
Used GitLab Runner version
Version: 13.7.0
Git revision: 943fc252
Git branch: 13-7-stable
GO version: go1.13.8
Built: 2020-12-21T13:47:06+0000
OS/Arch: linux/amd64
Possible fixes
Re-run test stage until cache has war file
Let's go step by step.
First, regarding how to manage the files between stages.
It's true that you could directly access to the files between jobs and stages if both run on the same environment, but that's not always the case (even if both runners are using the same nfs share directory) and you should use artifacts for that.
When you define an artifact within a job, you're specifying a list of files that are attached to the job when it succeeds, fails or always, depending on the configuration you have.
By default, all artifacts from previous stages are passed to each job, but in any case you can use dependencies to also define from which jobs you want to fetch artifacts from.
So basically you should use the following .gitlab-ci.yml
image: openshift/origin-cli
stages:
- build
- test
- staging
cache:
paths:
- .m2/repository
validate:jdk8:
stage: build
script:
- 'mvn test-compile'
only:
- master
image: maven:3.3.9-jdk-8
verify:jdk8:
stage: test
script:
- 'mvn verify' # =====> verify already includes: validate, compile, test and package
artifacts:
paths:
- target/[YOUR_APP_NAME].war
only:
- master
image: maven:3.3.9-jdk-8
staging:
dependencies:
- verify:jdk8
script:
- "mkdir -p artifact"
- "cp ./target/[YOUR_APP_NAME].war ./artifact/"
- "oc start-build $APP"
stage: staging
variables:
APP: $CI_PROJECT_NAME
environment:
name: staging
url: http://$CI_PROJECT_NAME-staging.$OPENSHIFT_DOMAIN
only:
- master
Also, notice that I deleted the mvn package instruction. I would recommend you to take a look into the Build Lifecycle Basics of Maven.

Why 1 out of 4 images isn't pushed into ECR

I could really learn some debugging techniques related to when images fail to be pushed into ECR on AWS.
I've got this "pusher" script:
#!/bin/sh
set -euo pipefail
if [ -z "$GITLAB_PULL_REQUEST" ] || [ "$GITLAB_PULL_REQUEST" == "false" ]
then
if [[ "$GITLAB_BRANCH" == "staging" ]]; then
export DOCKER_ENV=stage
elif [[ "$GITLAB_BRANCH" == "production" ]]; then
export DOCKER_ENV=prod
fi
if [ "$GITLAB_BRANCH" == "staging" ] || \
[ "$GITLAB_BRANCH" == "production" ]
then
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
unzip awscli-bundle.zip
./awscli-bundle/install -b ~/bin/aws
export PATH=~/bin:$PATH
export AWS_ACCOUNT_ID=27472596600
export AWS_ACCESS_KEY_ID=AKIAJGN7TUVKNORFB2A
export AWS_SECRET_ACCESS_KEY=M8GZei4Bf8aAWpcml1l7vzyedec8FkLWAYBSC7K
eval $(aws ecr get-login --region eu-west-2 --no-include-email)
export TAG=$GITLAB_BRANCH
export REPO=$AWS_ACCOUNT_ID.dkr.ecr.eu-west-2.amazonaws.com
fi
if [ "$GITLAB_BRANCH" == "staging" ] || \
[ "$GITLAB_BRANCH" == "production" ]
then
docker build $USERS_REPO -t $USERS:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $USERS:$COMMIT $REPO/$USERS:$TAG
docker push $REPO/$USERS:$TAG # SUCCESSFULLY PUSHED
docker build $USERS_DB_REPO -t $USERS_DB:$COMMIT -f Dockerfile
docker tag $USERS_DB:$COMMIT $REPO/$USERS_DB:$TAG
docker push $REPO/$USERS_DB:$TAG # SUCCESSFULLY PUSHED
docker build $SWAGGER_REPO -t $SWAGGER:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $SWAGGER:$COMMIT $REPO/$SWAGGER:$TAG
docker push $REPO/$SWAGGER:$TAG # SUCCESSFULLY PUSHED
docker build $CLIENT_REPO -t $CLIENT:$COMMIT -f Dockerfile-prod --build-arg REACT_APP_USERS_SERVICE_URL=""
docker tag $CLIENT:$COMMIT $REPO/$CLIENT:$TAG
docker push $REPO/$CLIENT:$TAG # LEFT OUT
fi
fi
Don't worry about the creds. They're not valid. I'm using GitLab CI and I can see no errors in the job log.
this is the job log of the image push:
Step 1/20 : FROM node:11.12.0-alpine as builder
---> 09084e4ff58d
Step 2/20 : WORKDIR /usr/src/app
---> Using cache
---> 7ee698668926
Step 3/20 : RUN apk add --no-cache --virtual .gyp python make g++
---> Using cache
---> a9f861b8e62f
Step 4/20 : ENV PATH /usr/src/app/node_modules/.bin:$PATH
---> Using cache
---> 5c3b377be213
Step 5/20 : COPY package.json /usr/src/app/package.json
---> 3a102c4e6b87
Step 6/20 : COPY package-lock.json /usr/src/app/package-lock.json
---> a92e6e57548b
Step 7/20 : RUN npm install --no-optional
---> Running in f62c36ac767e
> cypress#4.1.0 postinstall /usr/src/app/node_modules/cypress
> node index.js --exec install
Installing Cypress (version: 4.1.0)
[10:33:58] Downloading Cypress [started]
[10:33:59] Downloading Cypress 0% 0s [title changed]
[10:33:59] Downloading Cypress 1% 10s [title changed]
[10:33:59] Downloading Cypress 3% 7s [title changed]
[10:33:59] ...
...
[10:34:16] Unzipping Cypress 9% 149s [title changed]
[10:34:18] Unzipping Cypress 9% 172s [title changed]
[10:34:18] Unzipping Cypress 100% 0s [title changed]
[10:34:18] Unzipped Cypress [title changed]
[10:34:18] Unzipped Cypress [completed]
[10:34:18] Finishing Installation [started]
[10:34:18] Finished Installation /root/.cache/Cypress/4.1.0 [title changed]
[10:34:18] Finished Installation /root/.cache/Cypress/4.1.0 [completed]
You can now open Cypress by running: node_modules/.bin/cypress open
https://on.cypress.io/installing-cypress
added 2034 packages from 768 contributors and audited 38602 packages in 78.928s
found 1073 vulnerabilities (1058 low, 14 moderate, 1 high)
run `npm audit fix` to fix them, or `npm audit` for details
Saving cache
Uploading artifacts for successful job
00:01
Job succeeded
What debugging techniques I can use here ? Please ask if there's anything you need to know.
It happens for us as well. Seems like a concurrency problem

Bitbucket Pipeline: Store .pdf artifact after pdfLaTeX

I try to use Bitbucket's pipeline feature for a LaTeX git repository. I just want to build my .tex file and store the .pdf artifact to the repository download folder. I found some helpful guides here and a similar answer at SO.
This is my pipeline.yml
options:
docker: true
image: kaspersoerensen/latex-docker
pipelines:
default:
- step:
script:
- pdflatex --shell-escape TEST.tex # Build once
#- bibtex TEST # Build bibtex
- pdflatex -shell-escape TEST.tex # Build again
- pdflatex -shell-escape TEST.tex # And last time
- curl -X POST --user "${BB_AUTH_STRING}" "https://api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=#"TEST.pdf"
To setup curl I used this official guideline from Atlassian.
Everything seems to be okay and the build is successful without any errors.
Problem: My repository download folder does not contain any artifacts.
EDIT
Build output:
Build setup
4s
pdflatex --shell-escape TEST.tex
1s
pdflatex -shell-escape TEST.tex
1s
pdflatex -shell-escape TEST.tex
1s
curl -X POST --user "${BB_AUTH_STRING}" "https://api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=#"TEST.pdf"
<1s
Build teardown
Docker output:
time="2019-12-20T14:56:23.511294820Z" level=warning msg="could not change group /var/run/docker.sock to docker: group docker not found"
time="2019-12-20T14:56:23.511451739Z" level=warning msg="[!] DON'T BIND ON ANY IP ADDRESS WITHOUT setting --tlsverify IF YOU DON'T KNOW WHAT YOU'RE DOING [!]"
time="2019-12-20T14:56:23.544238141Z" level=warning msg="failed to load plugin io.containerd.snapshotter.v1.btrfs" error="path /var/lib/docker/165536.165536/containerd/daemon/io.containerd.snapshotter.v1.btrfs must be a btrfs filesystem to be used with the btrfs snapshotter"
time="2019-12-20T14:56:23.562813661Z" level=warning msg="failed to load plugin io.containerd.snapshotter.v1.aufs" error="modprobe aufs failed: "ip: can't find device 'aufs'\nmodprobe: can't change directory to '/lib/modules': No such file or directory\n": exit status 1"
time="2019-12-20T14:56:23.563473734Z" level=warning msg="failed to load plugin io.containerd.snapshotter.v1.zfs" error="path /var/lib/docker/165536.165536/containerd/daemon/io.containerd.snapshotter.v1.zfs must be a zfs filesystem to be used with the zfs snapshotter"
time="2019-12-20T14:56:23.563610398Z" level=warning msg="could not use snapshotter btrfs in metadata plugin" error="path /var/lib/docker/165536.165536/containerd/daemon/io.containerd.snapshotter.v1.btrfs must be a btrfs filesystem to be used with the btrfs snapshotter"
time="2019-12-20T14:56:23.563626718Z" level=warning msg="could not use snapshotter aufs in metadata plugin" error="modprobe aufs failed: "ip: can't find device 'aufs'\nmodprobe: can't change directory to '/lib/modules': No such file or directory\n": exit status 1"
time="2019-12-20T14:56:23.563636848Z" level=warning msg="could not use snapshotter zfs in metadata plugin" error="path /var/lib/docker/165536.165536/containerd/daemon/io.containerd.snapshotter.v1.zfs must be a zfs filesystem to be used with the zfs snapshotter"
time="2019-12-20T14:56:23.695604523Z" level=warning msg="Running modprobe bridge br_netfilter failed with message: ip: can't find device 'bridge'\nbridge 167936 1 br_netfilter\nstp 16384 1 bridge\nllc 16384 2 bridge,stp\nip: can't find device 'br_netfilter'\nbr_netfilter 24576 0 \nbridge 167936 1 br_netfilter\nmodprobe: can't change directory to '/lib/modules': No such file or directory\n, error: exit status 1"
time="2019-12-20T14:56:23.706219675Z" level=warning msg="Running modprobe nf_nat failed with message: `ip: can't find device 'nf_nat'\nnf_nat_ipv6 16384 1 ip6table_nat\nnf_nat_ipv4 16384 2 ipt_MASQUERADE,iptable_nat\nnf_nat 32768 3 nf_nat_ipv6,xt_nat,nf_nat_ipv4\nnf_conntrack 139264 8 nf_nat_ipv6,nf_conntrack_netlink,xt_nat,xt_conntrack,ip_vs,ipt_MASQUERADE,nf_nat_ipv4,nf_nat\nlibcrc32c 16384 3 ip_vs,nf_nat,nf_conntrack\nmodprobe: can't change directory to '/lib/modules': No such file or directory`, error: exit status 1"
time="2019-12-20T14:56:23.716309547Z" level=warning msg="Running modprobe xt_conntrack failed with message: `ip: can't find device 'xt_conntrack'\nxt_conntrack 16384 42 \nnf_conntrack 139264 8 nf_nat_ipv6,nf_conntrack_netlink,xt_nat,xt_conntrack,ip_vs,ipt_MASQUERADE,nf_nat_ipv4,nf_nat\nmodprobe: can't change directory to '/lib/modules': No such file or directory`, error: exit status 1"
I'd recommend to use the bitbucket-upload-file pipe instead of sending API requests with curl to upload files in Bitbucket. The pipe will provide better feedback if something is wrong. Here is an example how you could do that:
options:
docker: true
image: kaspersoerensen/latex-docker
pipelines:
default:
- step:
name: Build the pdf
script:
- pdflatex --shell-escape TEST.tex
artifacts:
- TEST.pdf
- step:
name: Upload
script:
- pipe: atlassian/bitbucket-upload-file:0.1.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
FILENAME: 'TEST.pdf'
Note, that I'm using to separate steps to build and upload, which is considered a good way to structure your pipelines.
Thanks to everyone who spent time to answer my question.
Now I found a working solution like this:
In general follow this nice written guide!
Be sure that you use two factor authentification!
BB_AUTH_STRING must be YOUR_USERNAME:YOUR_APP_PASSWORD (Don't use the App Password label! This was my fault)
Use the following .yml code.
.
image: dme26/latex-builder:latest
pipelines:
default:
- step:
script:
- pdflatex TEST.tex; pdflatex TEST.tex
- ls
- curl -X POST "https://${BB_AUTH_STRING}#api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=#"TEST.pdf"

NPM install keeps failing in the same place in when building Docker container on Ubuntu EC2

I've been trying to create some build automation scripts to be ran by a job on my Jenkins server on an Ubuntu EC2 instance. I want the script to remove any loose containers and images, then build the new version of my image and replace the running container. Here's my build script:
# Granting superuser
sudo -i
# Initializing Variables
_imagetag=nurenui-v1
# Initializing functions
buildImage()
{
docker build -t "$_imagetag" .
}
removeOldImage()
{
docker rmi $_imagetag
}
pruneImagesAndContainers()
{
docker container prune --force
docker image prune --force
}
pruneImagesAndContainers
if [ "$(docker images $_imagetag)" == "" ]; then
buildImage
else
removeOldImage
buildImage
fi
There were a few jobs that I ran that worked very well. But for some reason, today, the build keeps failing on NPM install in my Dockerfile:
FROM node as build-stage
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
FROM nginx:stable-alpine as production-stage
COPY --from=build-stage /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
NPM install works fine on my machine, but I can't test docker on it because I am still on Win8. If i try to build the docker image inside or outside of jenkins, I always get this:
17:30:22 Started by GitHub push by ObsidianTech
17:30:22 Building in workspace /var/lib/jenkins/workspace/UI/NuRenUI
17:30:22 [WS-CLEANUP] Deleting project workspace...
17:30:22 [WS-CLEANUP] Deferred wipeout is used...
17:30:22 [WS-CLEANUP] Done
17:30:22 using credential ab9c5d12-0a8d-4edb-9be4-83813cf29068
17:30:22 Cloning the remote Git repository
17:30:22 Cloning repository https://github.com/ObsidianTech/NuRenPivot.git
17:30:22 > git init /var/lib/jenkins/workspace/UI/NuRenUI # timeout=10
17:30:22 Fetching upstream changes from https://github.com/ObsidianTech/NuRenPivot.git
17:30:22 > git --version # timeout=10
17:30:22 using GIT_ASKPASS to set credentials
17:30:22 > git fetch --tags --progress https://github.com/ObsidianTech/NuRenPivot.git +refs/heads/*:refs/remotes/origin/*
17:30:23 > git config remote.origin.url https://github.com/ObsidianTech/NuRenPivot.git # timeout=10
17:30:23 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
17:30:23 > git config remote.origin.url https://github.com/ObsidianTech/NuRenPivot.git # timeout=10
17:30:23 Fetching upstream changes from https://github.com/ObsidianTech/NuRenPivot.git
17:30:23 using GIT_ASKPASS to set credentials
17:30:23 > git fetch --tags --progress https://github.com/ObsidianTech/NuRenPivot.git +refs/heads/*:refs/remotes/origin/*
17:30:24 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
17:30:24 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
17:30:24 Checking out Revision 53e55914222b3f53f173e313d2dc8c7c10746083 (refs/remotes/origin/master)
17:30:24 > git config core.sparsecheckout # timeout=10
17:30:24 > git checkout -f 53e55914222b3f53f173e313d2dc8c7c10746083
17:30:24 Commit message: "trying to fix npm issue"
17:30:24 > git rev-list --no-walk b01ea4d30b391f700a0c597a20bbb5ff6e6f552d # timeout=10
17:30:24 [NuRenUI] $ /bin/sh -xe /tmp/jenkins6764800963704352013.sh
17:30:24 + ls
17:30:24 Dockerfile
17:30:24 README.md
17:30:24 babel.config.js
17:30:24 package-lock.json
17:30:24 package.json
17:30:24 public
17:30:24 qaBuild.sh
17:30:24 qaDeploy.sh
17:30:24 src
17:30:24 + chmod 777 ./qaBuild.sh
17:30:24 + chmod 777 ./qaDeploy.sh
17:30:24 + ./qaBuild.sh
17:30:28 Deleted Containers:
17:30:28 9cd52dadac2f379dffc630d01f0ade2069b0a5683a0dce2c2261490529f75db6
17:30:28
17:30:28 Total reclaimed space: 138.6MB
17:30:28 Deleted Images:
17:30:28 deleted: sha256:0fbd6c6b36a785ecebe8f9ecc971e7645ef209a7a62de4996b773a37bee6b4a4
17:30:28 deleted: sha256:ba7d8f555b9eb7cf15dbda40569efe6171bddeeeaa0deced3816217690943f21
17:30:28 deleted: sha256:0ce9c7023bc64f5798954340ae9b44d9afe231b3e724351059dbd275e9e98c87
17:30:28 deleted: sha256:8b626fa0dcd67eab716ed8999e0fdbfe063c630685f7a77dfb592f15df93198c
17:30:28
17:30:28 Total reclaimed space: 421.3kB
17:30:28 ./qaBuild.sh: 23: [: REPOSITORY TAG IMAGE ID CREATED SIZE
17:30:28 nurenui-v1 latest c6fd05d82c12 13 hours ago 43.7MB: unexpected operator
17:30:28 Error response from daemon: conflict: unable to remove repository reference "nurenui-v1" (must force) - container e300a467c2e0 is using its referenced image c6fd05d82c12
17:30:29 Sending build context to Docker daemon 67.87MB
17:30:29 Step 1/10 : FROM node:latest as build-stage
17:30:29 ---> 502d06d3bfdf
17:30:29 Step 2/10 : WORKDIR /app
17:30:29 ---> Running in d12805e29d2e
17:30:30 Removing intermediate container d12805e29d2e
17:30:30 ---> 4f573ab1b889
17:30:30 Step 3/10 : COPY package*.json ./
17:30:30 ---> 9fc9cb7ed731
17:30:30 Step 4/10 : RUN npm install
17:30:30 ---> Running in 70fe3d18ecc4
17:31:03
17:31:03 > yorkie#2.0.0 install /app/node_modules/yorkie
17:31:03 > node bin/install.js
17:31:03
17:31:03 [91m
17:31:03 [0mThe command '/bin/sh -c npm install' returned a non-zero code: 1
17:31:05 Build step 'Execute shell' marked build as failure
17:31:05 Finished: FAILURE
I keep getting some kind of error about yorkie before it fails. I have no idea why this is happening or how to fix it.
Edit: package.json
{
"name": "nurenpivot",
"version": "0.1.0",
"private": true,
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"lint": "vue-cli-service lint"
},
"dependencies": {
"core-js": "^2.6.5",
"vue": "^2.6.6",
"vue-router": "^3.0.4",
"vuex": "^3.1.0"
},
"devDependencies": {
"#vue/cli-plugin-babel": "^3.5.0",
"#vue/cli-plugin-eslint": "^3.5.0",
"#vue/cli-service": "^3.5.0",
"babel-eslint": "^10.0.1",
"eslint": "^5.8.0",
"eslint-plugin-vue": "^5.0.0",
"vue-template-compiler": "^2.5.21"
},
"eslintConfig": {
"root": true,
"env": {
"node": true
},
"extends": [
"plugin:vue/essential",
"eslint:recommended"
],
"rules": {},
"parserOptions": {
"parser": "babel-eslint"
}
},
"postcss": {
"plugins": {
"autoprefixer": {}
}
},
"browserslist": [
"> 1%",
"last 2 versions",
"not ie <= 8"
]
}
Looking at your logs (before you deleted them from the original question), I could see that you have several errors in your build script way before the step in the Dockerfile where you do the npm install. For example, sudo was failing, the test with [ was also failing, to mention some.
This build script is actually very badly written, as it never checks for errors. Any problem would be simply ignored. When an important command can fail, you have to check the return code ($?) to be equal to zero, before you proceed. Another option you have is to stop on any error using set -e at the very beginning of the script.
As for the other errors, there's not enough information to help you. Please update the question with the complete logs, as they were before (just remove the sensitive parts) and with the contents of your package.json. It's also needed to check the npm and nodejs version running on Jenkins and on your machine, to check if they match.
Edit after logs were re-added to the question:
Looking at these lines of your logs:
17:30:28 ./qaBuild.sh: 23: [: REPOSITORY TAG IMAGE ID CREATED SIZE
17:30:28 nurenui-v1 latest c6fd05d82c12 13 hours ago 43.7MB: unexpected operator
17:30:28 Error response from daemon: conflict: unable to remove repository reference "nurenui-v1" (must force) - container e300a467c2e0 is using its referenced image c6fd05d82c12
It became clear that you are using the raw output from the command docker images $_imagetag, which is definitely not what you want. If you try this command, you'll see that the output contains a lot of other information, like a header, size, tag, etc. Even if the image doesn't exist, it outputs the header line. It's literally what the logs are telling you, something like this:
REPOSITORY TAG IMAGE ID CREATED SIZE
nurenui-v1 latest c6fd05d82c12 13 hours ago 43.7MB
To do that check, you have to add -q to the command. This way it won't output anything if the image is not found. Change that line to look like this:
if [ -n "$(docker images -q $_imagetag)" ]; then
removeOldImage
fi
buildImage
... but this is not the only problem you have. I can also see a container using that image... and I didn't even check the package.json.

Resources