Skip to content
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

Choosing the correct worker for a project #42

Open
bendikro opened this issue Dec 13, 2016 · 7 comments
Open

Choosing the correct worker for a project #42

bendikro opened this issue Dec 13, 2016 · 7 comments

Comments

@bendikro
Copy link
Contributor

I can't find a way to map a project to specific worker or worker types. Is this on the TODO list?
I see that travisyml.py has an image attribute, but it's currently not used as far as I can see? Is this meant to handle this in the future?

@tardyp
Copy link
Member

tardyp commented Dec 16, 2016

It is something that indeed is on the TODO list, and shall go via this image attribute.
Actually this is not very complicated to do as the image for docker latent worker is already renderable.

@bendikro
Copy link
Contributor Author

Yeah, I noticed that was supported for the DockerLatentWorker. Any idea about how this will be handled regarding the lang and image attributes? Say we implement support for LibVirtWorker, we'd need a way to specify which type of worker to use in the .travis.yml?

@tardyp
Copy link
Member

tardyp commented Dec 16, 2016

I'd say the best is for LibVirtWorker to have some of its parameter rendereable so that they can be chosen according to the properties.
Or improve the bbtravis.yml so that it is easier to describe what to do. I fully open to suggestion here

@pardoc
Copy link

pardoc commented Aug 21, 2017

I would also expect some support for Windows workers. So far, I only see Linux based ones. How hard would it be to implement an 'os' attribute (or a set of worker properties) in the bbtravis.yml ? Like this is currently supported in travis, although only for linux and macos.

@pardoc
Copy link

pardoc commented Sep 4, 2017

I plan to make a fork of buildbot_travis adding a "labels" attribute to Workers, in order to have a node selection mechanism "à la" Jenkins. But this requires to also change the Worker class in buildbot, and add it a "labels" attribute as well. Is there a way I can avoid this ?

@tardyp
Copy link
Member

tardyp commented Sep 4, 2017

In buildbot, the way you can do this is to implement and nextWorker callback. You can always add a attribute to your standard buildbot workers, and then look at this attribute in your nextWorker.

@pardoc
Copy link

pardoc commented Sep 5, 2017

I planned to use canStartBuild, but nextWorker will do as well. The problem is that checkConfig (buildbot.worker.base.AbstractWorker) returns an error on the unexpected "labels" argument I added (in the UI, cfg.yml, and createWorkerConfigWorker). I cannot see how to avoid modifying buildbot itself to make that pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants