We're using the Windows-2019 vmImage for our hosted build agents, which have both docker and docker-compose installed (https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md).
But as soon as we run any docker-compose command (whether 'up' or 'down' or other), we immediately hit an error with little feedback:
Error: 3/30/2020 2:09:06 PM:
At D:\a\1\s\psakefile.ps1:16 char:5 + docker-compose down + ~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Removing network s_default
##[error]PowerShell exited with code '1'.
Any ideas? Do we need to initialise something on the build agent first so that docker-compose works? Everything works locally tested against numerous machines.
Related
We have a Azure Pipeline to Build and deploy the Docker image.
Once deploy we need to check the deployed docker container status and fail the pipeline if contianer is not running.
We setup a yaml pipeline to build and deploy the Docker image which successfully deployed and contianer is running fine.
But we need to add a logic to get the contianer status if not running mark the pipeline as failed.
We used the below command to check the status.
sudo docker container ls --filter "name=$(module)" --filter "status=running"
I have tried to reproduce the same in my lab environment and got positive results after following the below steps.
Step 1: Add the below code snippet to the pipeline which causes the pipeline to fail if the container is not running.
- script: |
if docker ps | grep busy_wiles; then
echo 'Container is running'
else
echo 'Container is not running'
exit 1
fi
*Note: In the above code ‘busy_wiles’ is my container name.
Step 2: Run the pipeline and see the result.
• Below is the output when the container is running.
• Below is the output when the container is not running.
I am using Gitlab CI in my development for continuous integration. I have my gitlab-runner runnig on a ubuntu instance.
I have one application, where i use MongoDB v3.6. I have to do a database integration test in the test stage of my CI/CD.
prepare:
image: node:11.10.1-alpine
stage: setup
script:
- npm install --quiet node-gyp
- npm install --quiet
- npm install -g yarn
- chmod a+rwx /usr/local/lib/node_modules/yarn/bin/yarn*
- chmod a+rwx /usr/local/bin/yarn*
- yarn install
- cd client
- yarn install
- cd ../
- cd admin
- yarn install
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
- client/node_modules/
- admin/node_modules/
policy: push
app_testing:
image: node:11.10.1-alpine
services:
- name: mongo:3.6
stage: test
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
- client/node_modules/
- admin/node_modules/
script:
- yarn run test
- cd client
- yarn run test
- cd ../
- cd admin
- yarn run test
For every alternate pipeline, i am getting the below error in the app_testing( test ) stage.
ERROR: Job failed (system failure): Error response from daemon: Conflict. The container name "/runner-e7ce6426-project-11081252-concurrent-0-mongo-0" is already in use by container "0964b061b56d8995966f577e7354852130915228bac1a7513a773bbb82aeefaf". You have to remove (or rename) that container to be able to reuse that name.
Below is the full log of the specific job which is failing
Running with gitlab-runner 10.8.0 (079aad9e)
on SharedRunner-XYZGroup e7ce6426
Using Docker executor with image node:11.10.1-alpine ...
Starting service mongo:3.6 ...
Pulling docker image mongo:3.6 ...
Using docker image sha256:57c2f7e051086c7618c26a2998afb689214b4213edd578f82fe4b2b1d19ee7c0 for mongo:3.6 ...
ERROR: Preparation failed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Will be retried in 3s ...
Using Docker executor with image node:11.10.1-alpine ...
Starting service mongo:3.6 ...
Pulling docker image mongo:3.6 ...
Using docker image sha256:57c2f7e051086c7618c26a2998afb689214b4213edd578f82fe4b2b1d19ee7c0 for mongo:3.6 ...
ERROR: Preparation failed: Error response from daemon: Conflict. The container name "/runner-e7ce6426-project-11081252-concurrent-0-mongo-0" is already in use by container "0964b061b56d8995966f577e7354852130915228bac1a7513a773bbb82aeefaf". You have to remove (or rename) that container to be able to reuse that name.
Will be retried in 3s ...
Using Docker executor with image node:11.10.1-alpine ...
Starting service mongo:3.6 ...
Pulling docker image mongo:3.6 ...
Using docker image sha256:57c2f7e051086c7618c26a2998afb689214b4213edd578f82fe4b2b1d19ee7c0 for mongo:3.6 ...
ERROR: Preparation failed: Error response from daemon: Conflict. The container name "/runner-e7ce6426-project-11081252-concurrent-0-mongo-0" is already in use by container "0964b061b56d8995966f577e7354852130915228bac1a7513a773bbb82aeefaf". You have to remove (or rename) that container to be able to reuse that name.
Will be retried in 3s ...
ERROR: Job failed (system failure): Error response from daemon: Conflict. The container name "/runner-e7ce6426-project-11081252-concurrent-0-mongo-0" is already in use by container "0964b061b56d8995966f577e7354852130915228bac1a7513a773bbb82aeefaf". You have to remove (or rename) that container to be able to reuse that name.
I tried disabling secondary caches, it didn't work for me.
Now i don't know how to fix this issue. As a workaround, i have to trigger a new pipeline every time it fails, which of course no one likes, as the ultimate goal for anyone to automate things is to focus on most important things.
Any help on this would be appreciated.
Thanks in advance.
This is a known issue, see https://gitlab.com/gitlab-org/gitlab-runner/issues/4327. GitLab is re-using the same service container name. This approach fails if the previous container wasn't deleted in time.
If you read through the (long list of) comments you may discover some workarounds of which are among others:
limit concurrency to 1
increase your Runner's machine's IOPS (e.g. switch from HDD to SSD)
As we were facing the same issue with the Docker executor, we currently kind of worked around it by using the Docker+Machine executor. Although you can't really be sure to avoid that error, my experience is that jobs are running more reliably since then. The tradeoff, however, is that for each job a VM is provisioned that wants to be paid.
I'm trying to implement GitLab CI Pipelines to build and deploy an app.
In our project we have two branches: master and others.
For a particular branch(eg:p-01-sprint-04), I want to run a Pipeline in order to build the application and deploy the build on a test environment.
The build failed during execution.
This is how my .gitlab-ci.yml looks like:
stages:
- test
unit_test:
stage: test
script:
- composer install
- php artisan migrate
- php artisan db:seed
- composer require laravel/passport
- php artisan passport:client --personal
- php artisan storage:link
- php artisan serve
The build failed with these errors :
Running with gitlab-runner 11.8.0 (4745a6f3)
on gitlab-runner-gitlab-runner-64c48b5865-wx6wl BS2DZ3GP
Using Kubernetes namespace: gitlab
Using Kubernetes executor with image ubuntu:16.04 ...
Waiting for pod gitlab/runner-bs2dz3gp-project-924-concurrent-0tzq4t to be running, status is Pending
Waiting for pod gitlab/runner-bs2dz3gp-project-924-concurrent-0tzq4t to be running, status is Pending
Running on runner-bs2dz3gp-project-924-concurrent-0tzq4t via gitlab-runner-gitlab-runner-64c48b5865-wx6wl...
Cloning into '/mk2/billeterie/bo'...
Cloning repository...
Checking out 841a7daf as p-01-sprint-04...
Skipping Git submodules setup
$ composer install
/bin/bash: line 72: composer: command not found
ERROR: Job failed: command terminated with exit code 1
Log shows you use ubuntu:16.04 with kubernetesexecutor :
Using Kubernetes executor with image ubuntu:16.04 ...
composer is not installed in ubuntu:16.04 docker image.
Use composer image instead which provide phpand composer binaries.
I'm trying to run basic pipeline that should build my web-project using GitLab CI
My setup:
GitLab CE 10.1.4 on Ubuntu 16.04
GitLab Runner 10.1.0 on Windows 10 1703 with docker executor
Docker 17.09.0-ce-win33 (13620) on same Windows machine
.gitlab-ci.yml:
image: node:latest
cache:
paths:
- node_modules/
build:
script:
- npm install
- npm run build
And I get failed build with this output:
Running with gitlab-runner 10.1.0 (c1ecf97f)
on ****** (9366a476)
Using Docker executor with image node:latest ...
Using docker image sha256:4d72396806765f67139745bb91135098acaf23ce7d627e41eb4da9c62e5d6729 for predefined container...
Pulling docker image node:latest ...
Using docker image node:latest ID=sha256:cf20b9ab2cbc1b6f76e820839ad5f296b4c9a9fd04f3e74651c16ed49943dbc4 for build container...
ERROR: Job failed (system failure): dial http: unknown network http
I've thought that problem might happen because container can't access internet, but https://hub.docker.com/r/byrnedo/alpine-curl/ curl container got the data, so I think it's not the case.
UPD:
Problem occurs when GitLab runner try to attach to container.
Problem was in GitLab CI config (config.toml), docker host.
host = "http://127.0.0.1:2375" - wrong one
should be host = "tcp://127.0.0.1:2375"
Trying out gitlab and trying to build a simple create-react-app project. However, I'm having issues with the gitlab-runner. I'm running gitlab on an EC2 instance using the AMI from gitlab that's in the amazon marketplace.
by yml is really basic.
build-site:
image: node:9
stage: build
script:
- npm install
- npm run build
artifacts:
expire_in: 1 week
paths:
- build
However the output I get in the gitlab web UI is
Running with gitlab-runner 10.1.0 (c1ecf97f)
on runner-1 (9fc6bc1c)
Using Shell executor...
Running on ip-10-214-239-156...
Fetching changes...
warning: failed to remove builds/0/project-0.tmp/git-template/config
warning: failed to remove builds/0/project-0/.istanbul.yml
warning: failed to remove builds/0/project-0/yarn.lock
warning: failed to remove builds/0/project-0/src/Root.js
warning: failed to remove builds/0/project-0/src/utils/common.js
and the output I get when running sudo gitlab-runner --debug exec shell build-site when ssh'ed into the ec2 machine
ERROR: Job failed: exit status 1
FATAL: exit status 1
had to add user gitlab-runner to docker group
usermod -aG docker gitlab-runner
seems to have done the trick