I’m trying to create a CI/CD Pipeline for a simple java/maven project.
The runner that I’m using is a docker runner.
I’m using a dockerfile
to create a container which installs maven/java/etc.. and in this container the program should be tested.
Sorry for the question but I am new to CI/CD Pipelines in GitLab.
GitHub works just fine have a look: https://github.com/ni920/CICD-Test
Thank you
Here are the CI logs
...
Executing "step_script" stage of the job script
$ docker build --build-arg JAVA_VERSION=openjdk7
/bin/sh: eval: line 95: docker: not found
Cleaning up file based variables
ERROR: Job failed: exit code 127
Thats the .gitlab-ci.yml
stages:
- java7
# - java11
# - deploy
java7:
stage: java7
script:
- docker build --build-arg JAVA_VERSION=openjdk7
# tags:
# - docker
#java11:
# stage: java11
# script:
# - docker build --build-arg JAVA_VERSION=openjdk11
# tags:
# - docker
Thats the dockerfile
# Pull base image.
FROM alpine as build
ARG MAVEN_VERSION=3.6.1
ARG USER_HOME_DIR="/root"
ARG JAVA_VERSION=openjdk7
ARG BASE_URL=https://apache.osuosl.org/maven/maven-3/${MAVEN_VERSION}/binaries
ENV HTTP_PROXY=#comment
ENV HTTPS_PROXY=#comment
# Install Java.
RUN apk --update --no-cache add JAVA_VERSION curl
RUN mkdir -p /usr/share/maven /usr/share/maven/ref
&& curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz
&& tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1
&& rm -f /tmp/apache-maven.tar.gz
&& ln -s /usr/share/maven/bin/mvn /usr/bin/mvn
ENV MAVEN_HOME /usr/share/maven
ENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"
# Define working directory.
WORKDIR /data
# Define commonly used JAVA_HOME variable
ENV JAVA_HOME /usr/lib/jvm/default-jvm/
# Define default command.
CMD ["mvn", "--version"]
Alex Bravo
1,5922 gold badges26 silver badges40 bronze badges
asked Jun 10, 2021 at 8:13
Running your pipelines using the Docker executor means that your jobs will run in a Docker container, but not that you will be able to execute docker
commands.
If you need to run docker
commands inside a GitLab CI job (read «inside a container») you will need Docker-in-Docker (often abbreviated DinD). It is a vast topic on itself but you can get started with GitLab CI‘s documentation: Use Docker to build Docker images
I always use DinD and have a minimal setup in my gitlab-ci.yml.
Using a docker image as a default:
image: docker:19.03.13
Define a default variable for TLS certificates:
variables:
DOCKER_TLS_CERTDIR: "/certs"
Then use a docker image as a service to enable DinD:
services:
- name: docker:19.03.13-dind
alias: docker
I wrote a few posts about using Docker-in-Docker on GitLab CI that you may find useful, but I still recommend to extensively read GitLab‘s documentation before reading them.
answered Jun 10, 2021 at 8:19
AymDevAymDev
5,9304 gold badges30 silver badges49 bronze badges
Open
Issue created Feb 14, 2020 by Mauricio Quiroga@quirogamauricio💬
Jobs using GitLab’s AWS Docker Image are failing
Summary
(Summarize the bug encountered concisely)
Jobs using GitLab’s AWS Docker Image are failing with the following error:
aws: not found
Steps to reproduce
Basically, follow the steps and guidelines described here: https://docs.gitlab.com/ee/ci/cloud_deployment/
- Create a repository in GitLab
- Add AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env variables in CI/CD settings section of the repo
- Add a .gitlab-ci-yml file to that repo
- Add the following job to that gitlab-ci.yml file:
test-aws:
image: registry.gitlab.com/gitlab-org/cloud-deploy:latest
script:
- aws s3 ls
Example Project
https://gitlab.com/mauricio.quiroga/gitlab-aws-docker-image-bug
What is the current bug behavior?
The job fails with the following message:
/bin/sh: eval: line 96: aws: not found
ERROR: Job failed: exit code 127
What is the expected correct behavior?
The job should succed and execute the specified commands
Job succeded
Relevant logs and/or screenshots
Running with gitlab-runner 12.7.1 (003fe500)
on docker-auto-scale 0277ea0f
Using Docker executor with image registry.gitlab.com/gitlab-org/cloud-deploy:latest ...
00:20
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/gitlab-org/cloud-deploy:latest ...
Using docker image sha256:a4fcb867dfdc1b0bafc8b6faf605f0d59775c0e16b8e63365e2656b53feb28f1 for registry.gitlab.com/gitlab-org/cloud-deploy:latest ...
Running on runner-0277ea0f-project-16915506-concurrent-0 via runner-0277ea0f-srm-1581710384-cf445603...
00:04
$ eval "$CI_PRE_CLONE_SCRIPT"
00:01
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/mauricio.quiroga/gitlab-aws-docker-image-bug/.git/
Created fresh repository.
From https://gitlab.com/mauricio.quiroga/gitlab-aws-docker-image-bug
* [new ref] refs/pipelines/118060861 -> refs/pipelines/118060861
* [new branch] master -> origin/master
Checking out aa45395c as master...
Skipping Git submodules setup
Authenticating with credentials from job payload (GitLab Registry)
00:02
$ aws s3 ls
/bin/sh: eval: line 88: aws: not found
ERROR: Job failed: exit code 127
Output of checks
This bug happens on GitLab.com
Edited Feb 21, 2020 by Mauricio Quiroga
Problem
Exit code 127 means job’s command can not be found or executed
Resolving The Problem
A job fails with exit code 127. What does exit code 127 mean?
>bjobs -l
..
Thu Nov 18 18:39:28: Exited with exit code 127. The CPU time used is 0.1 seconds.
Thu Nov 18 18:39:28: Completed .
There are two possible meanings:
- · The job exits with exit code 127. Ex. «exit 127» or «return(127)”
- · If LSF returns 127, it means a command in the job is not found or executable.
Refer to «Understanding Platform LSF job exit information” in «Platform LSF Configuration Reference” for more details.
[{«Product»:{«code»:»SSWRJV»,»label»:»IBM Spectrum LSF»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»—«,»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Version»:»Version Independent»,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}},{«Product»:{«code»:»SSWRJV»,»label»:»IBM Spectrum LSF»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:null,»Platform»:[{«code»:»»,»label»:»»}],»Version»:»»,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]
0
1
Всем привет. Какая-то странная фигня. Сделал примитивный сервис и пытаюсь его запустить, а в ответ получаю:
Job for test.service failed because the control process exited with error code.
See "systemctl status test.service" and "journalctl -xe" for details.
где написано следующее:
Jul 04 12:23:03 spider systemd[1]: Starting Мой тестовый сервис...
Jul 04 12:23:03 spider systemd[1]: test.service: Control process exited, code=exited status=127
Jul 04 12:23:03 spider systemd[1]: Failed to start Мой тестовый сервис.
Jul 04 12:23:03 spider systemd[1]: test.service: Unit entered failed state.
Jul 04 12:23:03 spider systemd[1]: test.service: Failed with result 'exit-code'.
Вот так выглядит сам сервси:
[Unit]
Description=Мой тестовый сервис
After=network.target
[Service]
Type=simple
User=spider
Group=spider
WorkingDirectory=/home/spider/src/test
ExecStartPre=/bin/echo "OPTS=$OPTS_COMMON">/tmp/run.log
ExecStart=/usr/bin/node test.js >/tmp/run.log 2>&1
Restart=no
RestartSec=10
[Install]
WantedBy=multi-user.target
Как-то так.
Всё бы ничего, но! Если убрать User/Group из сервиса, то всё запустится и будет работать. Но с ними не работает. Я сам как Юзер могу запускать сервис.
ExecStartPre добавлено для проверки, что вообще хоть что нить происходит или нет. И не происходит со следующей отпиской:
$ sudo systemctl status test.service
● test.service - Мой тестовый сервис
Loaded: loaded (/lib/systemd/system/test.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-07-04 12:22:31 +06; 2s ago
Process: 24128 ExecStartPre=/bin/echo OPTS=$OPTS_COMMON>/tmp/run.log (code=exited, status=127)
Main PID: 21783 (code=exited, status=1/FAILURE)
Как так то?! Чего? 127 — это же Command not found? Чего он не нашёл? echo?
spider@spider ~/src/test $ whereis echo
echo: /bin/echo
да вроде находит…
Что не так я делаю?