<p>I am experimenting with running jenkins on kubernetes cluster. I have achieved running jenkins on the cluster using helm chart. However, I'm unable to run any test cases since my code base requires python, mongodb</p>
<p>In my JenkinsFile, I have tried the following</p>
<p>1.</p>
<pre><code>withPythonEnv('python3.9') {
     pysh 'pip3 install pytest'
}
</code></pre>
<ol start="2">
<li></li>
</ol>
<pre><code>stage('Test') {
    sh 'python --version'
}
</code></pre>
<p>But it says <code>java.io.IOException: error=2, No such file or directory</code>.
It is not feasible to always run the python install command and have it hardcoded into the JenkinsFile. After some research I found out that I have to declare kube to install python while the pod is being provisioned but there seems to be no PreStart hook/lifecycle for the pod, there is only PostStart and PreStop.</p>
<p>I'm not sure how to install python and mongodb use it as a template for kube pods.</p>
<p>This is the default YAML file that I used for the helm chart - <a href="https://raw.githubusercontent.com/jenkinsci/helm-charts/main/charts/jenkins/values.yaml" rel="nofollow noreferrer">jenkins-values.yaml</a>
Also I'm not sure if I need to use helm.</p>

Vaibhav
<p>You should create a new container image with the packages installed. In this case, the Dockerfile could look something like this:</p>
<pre><code>FROM jenkins/jenkins
RUN apt install -y appname
</code></pre>
<p>Then build the container, push it to a container registry, and replace the &quot;Image: jenkins/jenkins&quot; in your helm chart with the name of the container image you built plus the container registry you uploaded it to. With this, your applications are installed on your container every time it runs.</p>
<p>The second way, which works but isn't perfect, is to run environment commands, with something like what is described here:
<a href="https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/</a>
the issue with this method is that some deployments already use the startup commands, and by redefining the entrypoint, you can stop the starting command of the container from ever running, thus causing the container to fail.
(This should work if added to the helm chart in the deployment section, as they should share roughly the same format)</p>
<p>Otherwise, there's a really improper way of installing programs in a running pod - use <code>kubectl exec -it deployment.apps/jenkins -- bash</code> then run your installation commands in the pod itself.</p>
<p>That being said, it's a poor idea to do this because if the pod restarts, it will revert back to the original image without the required applications installed. If you build a new container image, your apps will remain installed each time the pod restarts. This should basically never be used, unless it is a temporary pod as a testing environment.</p>
