« Django Testing Mailing List | Using ZNC, an IRC bouncer »
When I was setting up the Django Hudson instance, I ran into a problem that seems like it should be pretty easy to solve. However, I couldn't figure out a way. So at this point it's looking like we're going to have to use buildbot to build out what we want instead of Hudson. Wondering if I missed something obvious, or if this is a missing feature.
We have our builds segmented currently by Django version and database. So to get something up and going, we have a Django trunk and 1.2.X build going against sqlite. We use a matrix build to run this against python 2.4-2.6, which means 3 builds in total for each Django version.
However, I can't find a way to make the matrix build choose the slave to run on based on what version of python it supports. I want to be able to randomly add slaves to the Hudson configuration, and have them pick up builds based off of their capabilities.
Hudson supports the idea of tagging, so we came up with a tagging scheme for the slaves. So it seems that we should be able to tell a test to run on any slave tagged with the versions of python we want. Hudson also supports this, but it runs all the tests across all the different slaves each time. I need it to have a pool of workers capable of running a set of tests, but run each test on only one of the members of the pool.
I was wondering if we're doing it wrong, or if other people know the correct way to run tests across a set of slaves, based on the capabilities of the slave? This seems like a pretty basic requirement for people running any kind of sizable Hudson configuration.
Posted at 7 p.m. on November 4, 2010
Comments: 1
Should reusable apps have templates?
Announcing Django Crawler and django-test-utils
Django stands for Awesome
Welcome to the home of Eric Holscher on the web. I talk about software development, mostly in the realm of Django. I am interested in the real time web, testing, mobile apps, and other things.
Why Read the Docs matters
3 months, 3 weeks ago (Comments: 7)
Read the Docs Update
1 year, 1 month ago (Comments: 2)
Using Reviewboard with Git
1 year, 3 months ago (Comments: 0)
Read the Docs Updates
1 year, 4 months ago (Comments: 1)
Handling Django Settings Files
1 year, 4 months ago (Comments: 12)
Required Reading
1 year, 6 months ago (Comments: 0)
Using Haystack to index non-database content
1 year, 6 months ago (Comments: 4)
Correct commands to check out and update VCS repos
1 year, 6 months ago (Comments: 0)
Site upgrades
1 year, 6 months ago (Comments: 0)
Building a Django App Server with Chef: Part 4
1 year, 6 months ago (Comments: 1)
Large Problems in Django, Mostly Solved: Delayed Execution
Setting up Django and mod_wsgi
Building a Django App Server with Chef: Part 1
Screencast: Django Command Extensions
Big list of Django tips (and some python tips too)
Handling Django Settings Files
Lessons Learned From The Dash: Easy Django Deployment
Building a Django App Server with Chef: Part 2


Comments
1 Wes Winham says...
This doesn't actually answer your question, but have you considered setting each slave up with multiple virtualenvs running the versions of python you want to test so that they can all run every test? It's kind of a workaround, but it's what I'm doing right now to get around a similar issue.
I'd like to know how to do exactly what you're asking in Hudson too.
Posted at 5:22 p.m. on November 5, 2010