How to execute a .sh file in gitlab-runner docker executor

How to Use GitLab
, , ,
1

Hi Team,

Here my case is , i have registered a new runner(docker executor), now i want to run two .sh files in docker container(runner).

what my two .sh files will do generally is, first file will check whether docker is installed or not if not it will install.

second .sh file will do my docker image build.

now when i run this two file on shell executor i get my images, and if i want to do SASt for this, SAST will only work in docker executor(correct me if i am wrong on this), so i added executor and trying to run these two .sh scripts, i fail to figure out that how to execute these two .sh files in container.

Could some one help me with how to run .sh scripts in docker container and SAST analysis in container???

PS- i can skip the first file coz running docker installation in docker conatiner is absurd(i believe)

Thanks,
Vamsi Krishna

2

Hi @vamzekr25 can you post your existing .gitlab-ci.yml file?

1 Like
3

stages:

  • build
  • test
  • deploy
  • review
  • dast
  • staging
  • canary
  • production
  • incremental rollout 10%
  • incremental rollout 25%
  • incremental rollout 50%
  • incremental rollout 100%
  • performance
  • cleanup

build-job:
image: ubuntu:20.04 # This job runs in the build stage, which runs first.
stage: build
script:
- whoami
#- chmod ug+x /home/gitlab-runner/builds/YaNn632S/0/orion/*
- chmod +x ./docker_install.sh
- chmod +x ./docker_orion.sh

Here, chmod ug+x line works on shell executor and next two lines are just passing job succeed in docker container, but no images are being build.

one more question:-

Instead of SAST analysis in gitlab-ci.yml file can i do sonnarscanner-cli in test stage in docker container… will that work???

PS - when repo checkout and initialize what is default path directory in docker executor???
i don’t see the repo copied files in container, it’s initalizing in local not in container.

4

Hi @vamzekr25

It’s still a little unclear to me what’s happening here. This is your build job:

build-job:
    image: ubuntu:20.04
    stage: build
    script:
        - whoami
        - chmod +x ./docker_install.sh
        - chmod +x ./docker_orion.sh

You say

Here, chmod ug+x line works on shell executor and next two lines are just passing job succeed in docker container, but no images are being build.

but there are no lines after the last chmod?

When your job starts, if it is running in a Docker runner, then you will start in whatever WORKDIR is defined for that container (defined by image), and your repo will cloned. The first line of your before_script or script will start in the root of your repo.

I’m not sure why you want to check whether Docker is installed, but just to be clear, if you are running on a Docker executor, then you are checking whether Docker is installed inside the container, not in the host.

1 Like
5

The chmod ug+X line commented you can ignore that.

From the below screenshot of config.toml file the blue marked are changed, i added builds_dir and changed default ruby:2.7 image to ubuntu.
image

here WORKDIR defined by image has any affect from the changes i made ???

the docker_orion.sh script will not run untill the install.sh script success, yeah i know it will check inside, not in host, is there any case script is running in container and Docker installation checking from host side… ha ha ha (absurd que i guess)

Here is the output when i try to run the sec script manually in container, in container it’s checking for docker. BTW it’s because i run the container on ubuntu base image(that acts as OS) from the first picture???

image
image740×420 8.76 KB

6

I think you might be right about the build_dir, the documentation is very helpful here.

If you want to check that Docker is installed in the host, not in the container, then you need a different job in your CI config, which runs on a shell runner, and performs that test.

The purpose of Docker is to isolate computation from the host, so it isn’t easy to run a command on the host from within the container (and you might think this isn’t a great idea, security wise!). There are some SO answers on this that might point you in a useful direction, but in my view running a separate job in a shell runner is more idiomatic and safer.

2 Likes