-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Python agent #15
Add Python agent #15
Conversation
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
(for info, the build is not failing because of your change, but because of jenkins-infra/pipeline-library#287) |
Build fixed. |
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.
It is not.
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? |
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. |
Closing the PR then given that: |
Like #14 but for Python. Tested locally with
docker build
.CC @dduportal @timja