Add Python agent

[basil]

Like #14 but for Python. Tested locally with docker build.

CC @dduportal @timja

[dduportal]

Hello @basil , what is the reason to add this image? Is there a new project in jenkinsci that requires python?

[timja]

Hello @basil , what is the reason to add this image? Is there a new project in jenkinsci that requires python?

I assume related to jenkinsci/packaging#239 (comment)

[dduportal]

Thanks for the proposal, it looks really good technically but I'm going to block the PR for the following reasons:

• Automated testing with Molecule jenkinsci/packaging#239 (comment) => if this is needed for the molecule tests, then we would want to use VMs for this (there isn't any possibility to run safely docker in containers, and kubernetes jenkins plugin requires us to build all-in-ine image which is costing a LOT of time and money while VMs as agents is really convenient and cheap).
• There is a work currently going on in feat(jenkins-agent) Add a docker build next to AWS and Azure (linux only) packer-images#164 to move all the Dockerfile located in this repo into packer workload (the goal is to ensure the same developer experience, wether you run in a container or in a VM, instead having to switch between containers and agents for a single set of tasks).

[dduportal]

(for info, the build is not failing because of your change, but because of jenkins-infra/pipeline-library#287)

[dduportal]

Build fixed.

[basil]

what is the reason to add this image? Is there a new project in jenkinsci that requires python?

There is no specific reason, and I had no particular project in mind. Python is my preferred scripting language, so I wanted to have the flexibility to use it for future projects or experiments. We also offer Ruby and JavaScript, so it seemed natural to also offer Python as a choice.

if this is needed for the molecule tests

It is not.

There is a work currently going on in jenkins-infra/packer-images#164 to move all the Dockerfile located in this repo into packer workload

But that PR is in draft state, while this PR is in non-draft state with a clean build and therefore ready to merge. So I see no reason why that PR should block this one.

[dduportal]

But that PR is in draft state, while this PR is in non-draft state with a clean build and therefore ready to merge. So I see no reason why that PR should block this one.

That's correct, the draft state of the other PR is not the reason to block adding a new kind of agent on the infrastructure: I poorly phrased my comment and I aplogize for that.

The reason I'm invoking to block this PR is that there is no reason for the infrastructure to support yet another dependency without a requirement that would have been discussed before at least for knowledge sharing. The current Jenkins infra allows to work with python when using a VM agent, so unless I'm missing something it is not a blocker.

Also this repository (jenkins-infra/docker-inbound-agent) is a fork of https://github.com/jenkinsci/jnlp-agents, to only aim at the jenkins-infra scope. Maintaining an exploding list of OS/image/dependencies is too much work for now that distract the team to fulfill their current obligation: hence it is a temporary "no" (unless, again, it is blocking).

This proposal to have a python agent would totally have a great value to be proposed to https://github.com/jenkinsci/jnlp-agents, which have a different set of reviewer, maintainers and users. If there is an image build from this, that could be a good feature request (to be raised in jenkins-infra/helpdesk) to add to ci.jenkins.io: does it sound a good idea?

[basil]

I don't see a high maintenance burden associated with this PR, and I would like the flexibility of using this image in my experiments. I am not going to wrestle with you in PR comments. This will be my last comment in this thread. Take it or leave it: it's your choice.

[dduportal]

Closing the PR then given that:

• Install Python 3 packer-images#167
• [updatecli] Bump agent templates version on all controllers (0.12.0) jenkins-infra#2046