skip to Main Content

I’m trying to set up a docker agent for this pipeline, but I’m getting this error when running one of the commands inside my pipeline:

+ poetry shell
Spawning shell within /root/.cache/pypoetry/virtualenvs/python-project-template-nESIvdvh-py3.11

(25, 'Not a tty')

From what I’ve looked at, this is because jenkins executes docker run with the -t argument by default. I understand that removing the -t flag would fix this issue, but I can’t find a way to do it. I’ve looked everywhere for ways to disable this (plus some other default flags) but I haven’t found a workaround.

This is what my current Jenkinsfile looks like

pipeline {
    agent { docker {
        image 'matiasch/python3.11-poetry1.7'
        args '-u root --privileged'
    } }
    stages {
        stage('Install Dependencies') {
            steps {
                timeout(time: 5, unit: 'MINUTES') {
                    sh 'poetry install'
                    sh 'poetry shell'
                }
            }
        }
    }
}

And this is the docker run commands jenkins executes, as you can see, there are some default flags I haven’t specified before the ones I added in my Jenkinsfile, -t being one of them.
docker run -t -d -u 1001:1001 -u root --privileged -w /home/jenkins/workspace/Python_Project_Template_main -v ...

I have tried switching from a declarative pipeline to a scripted one, using different docker images, trying to find some command that ‘negates’ -t, looking in the jenkins/plugin configuration for default flags, but I can’t find something that would fix the issue at its core which is to disable the default flags.

2

Answers


  1. I think because of adding the -t flag to the docker run command, which is causing problems with your Poetry shell command. Since removing the -t flag seems to be the solution, but you’re having trouble finding a way to do it, let’s try a workaround.

    use the docker tool directly within your Jenkins pipeline script instead of relying on the declarative syntax. This gives you more control over the Docker command being executed.

    first declare agent none to indicate that we won’t be using any default agent. Then, within the steps block of the Run Docker stage, we use the docker.image('image_name').inside syntax to run commands inside the specified Docker container. This should bypass Jenkins automatic addition of the -t flag.

    try this:

    pipeline {
        agent any
        stages {
            stage('Run Docker') {
                agent {
                    docker {
                        image 'matiasch/python3.11-poetry1.7'
                        args '-u root --privileged'
                    }
                }
                steps {
                    script {
                        // Run poetry commands within the Docker container
                        docker.image('matiasch/python3.11-poetry1.7').inside {
                            sh 'poetry install'
                            sh 'poetry shell'
                        }
                    }
                }
            }
        }
    }
    
    
    Login or Signup to reply.
  2. From the comments:

    The docker jenkins plugin has been confusing for us for quite some time because of these default arguments. What we have been doing, using a normal runner we are just running sh "docker run …." commands ourselves

    How would this look? Do you have an extra stage before your other ones where you do the setup of the docker container?

    We have a Dockerfile

    FROM matiasch/python3.11-poetry1.7
    RUN poetry install && poetry shell
    

    Then we can test stuff locally, typically from Makefile or justfile:

    docker build .
    docker run --rm $(docker build -q .) some test commands
    

    And then we do the same in jenkins:

    pipeline {
        agent {}
        stages {
            stage('Install Dependencies') {
                steps {
                    timeout(time: 5, unit: 'MINUTES') {
                        sh 'docker build .'
                        sh 'docker run --rm $(docker build -q .) some test commands'
                    }
                }
            }
        }
    }
    

    It is also sometimes nice to put testing commands inside Dockerfile to re-use the caching properties of docker layers.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search