Container doesn't start correctly in Jenkins pipeline

[mkilivan]

I run Jenkins in Docker on Ubuntu 16.04 machine. I added a new pipeline item in Jenkins. The declarative pipeline is shown below.

Jenkinsfile (Declarative Pipeline)

pipeline {
    agent {
        docker {
            image 'crops/poky'
        }
    }
    stages {
        stage('Stage 1') {
            steps {
                sh 'uname -a'
            }
        }
    }
}

I got the following error when I run the build.

ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
Alternatively you can force image entrypoint to be disabled by adding option --entrypoint=''.

What's wrong with the ENTRPOINT?

Is this correct way to use crops/poky in Jenkins pipeline?

[mkilivan]

It seems the container stops running when it starts with the user id 1000

$ docker run -t -u 1000:1000 crops/poky

sudo: unknown uid 1000: who are you?
Traceback (most recent call last):
  File "/usr/bin/usersetup.py", line 82, in <module>
    grp.getgrgid(args.gid)
KeyError: 'getgrgid(): gid not found: 1000'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/usersetup.py", line 85, in <module>
    subprocess.check_call(cmd.split(), stdout=sys.stdout, stderr=sys.stderr)
  File "/usr/lib/python3.6/subprocess.py", line 311, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', 'restrict_groupadd.sh', '1000', 'pokyuser']' returned non-zero exit status 1.

[rewitt1]

Hi @mkilivan,

I reproduced the issue as well. Since crops/poky has a USER line in its dockerfile, overriding that user prevents the automatic creation of a user that matches the owner of the workdir specified. Technically there isn't anything wrong with the entrypoint, it's that using the docker agent doesn't honor the USER in the image.

Until I could spend some more time figuring out if there is a way to address this for the crops/poky container, I think there are a couple of ways to still use jenkins.

1. Use https://github.com/crops/yocto-dockerfiles. These are the base images for crops/poky. They aren't tested quite as much(and I should write some documentation). They also don't run dumb-init by default. However, dumb-init is installed in the image or you could use the --init argument to docker run.

   Here is an example that worked for me. Note: I am not a Jenkins expert by any means and don't use it on a regular basis

   def workspace = env.WORKSPACE                                               
                                                                               
   pipeline {                                                                  
       agent none                                                              
       stages {                                                                
           stage('build') {                                                    
               agent {                                                         
                   docker {                                                    
                       image 'crops/yocto:ubuntu-18.04-base'                   
                       args '--init'                                           
                   }                                                           
               }                                                               
               steps {                                                         
                   git changelog: false, poll: false, url: 'https://git.yoctoproject.org/git/poky'
                   sh 'uname -a'                                                                                                  
                   sh 'export LANG=en_US.UTF-8 && . ./oe-init-build-env && bitbake quilt-native'
               }                                                               
           }                                                                   
       }                                                                       
   }
   

2. Instead of using the docker agent, use "Image.run()" or similar as documented here: https://docs.cloudbees.com/docs/admin-resources/latest/plugins/docker-workflow. I have not personally attempted this, but I don't see any reason why it wouldn't work as well. I'm not sure how it delegates to nodes vs. the agent, as I said I'm no expert.

Regardless of which method you end up using, if you end up using this in a production environment, I also recommend that you build the container images yourself and preserve them if you desire reproducibility. This is the only way to ensure the image contains the exact same files it had the last time you built, because there aren't versioned images stored on dockerhub.

Hopefully one of the above suggestions allows you to proceed.