Jenkins (and It's predecessor Hudson) are useful projects for automating common development tasks (e.g. unit-testing, production batches) - but they are somewhat Java-centric. Thankfully the designers have provided an excellent and complete REST interface. This library wraps up that interface as more conventional python objects in order to make many Jenkins oriented tasks easier to automate. This library can help you: Query the test-results of a completed build Get objects representing the latest builds of a job Search for artefacts by simple criteria Block until jobs are complete Install artefacts to custom-specified directory structures username/password auth support for jenkins instances with auth turned on Ability to search for builds by subversion revision Ability to add/remove/query Jenkins slaves Ability to add/remove/modify Jenkins views
Well I could add this inside a half hour if I set my mind to it and all went smoothly. However, generally requests like this come with an ebuild submitted here with the bug. In this case nothing. What are your expectations here? Team or herd python has more or less a closed shop policy on adding new ebuilds to team or herd python. Already too many packages and such. It can though be added via other means. Ball in your court as to selecting one of those paths.
Created attachment 394698 [details] jenkinsapi-0.2.26.ebuild
good basic ebuild. 1 PYTHON_COMPAT=( python{2_7,3_3} ) add 3_4 and pypy. You only need have py3.4 emerged. Team python has been adding py3.4 support solidly since it was released. Addition of pypy is optional seeing its user base is quite a mystery. I have thrown it in 2. ALL deps are in dev-python/. ALL deps inherit a new eclass, therefore ALL deps need have [${PYTHON_USEDEP}] added in the form of a suffix. e.g. dev-python/nose[${PYTHON_USEDEP}] 3. While there are cases where a dep can be listed without [${PYTHON_USEDEP}], they are rare and don't apply here. 4. See work/jenkinsapi-0.2.26/jenkinsapi.egg-info/requires.txt and work/jenkinsapi-0.2.26/setup.py. In both you will find version borders set. So we end up with 4. DEPEND="dev-python/pytz dev-python/requests becomes RDEPEND=">=dev-python/pytz-2014.4[${PYTHON_USEDEP}] >=dev-python/requests-2.3.0[${PYTHON_USEDEP}] 5. Note in setup.py. from setuptools import setup. This means setuptools is required in DEPEND, so we need DEPEND=dev-python/setuptools[${PYTHON_USEDEP}] 6. the test IUSE flag belongs under DEPEND and the tests require all packages of RDEPEND. 7. dev-python/mock is a special case. I shall just hold off with that for now since there is more than enough here already. python_test() { esetup.py test } is fully correct ONCE the required deps are emerged. ~/improvise/dev-python/jenkinsapi $ ebuild jenkinsapi-0.2.26.ebuild clean test yields Ran 0 tests in 2.796s \ OK Ran 0 tests in 0.141s \ OK Ran 0 tests in 0.127s \ OK Ran 0 tests in 0.906s \ OK over the 4 impls. So, good start. See if you can attach a revised ebuild that matches or equates to the one I have. This would be added with you as proxy maintainer, with or without <herd>proxy-maintainers</herd> listed in metadata.xml. It's a fairly basic package -> ebuild and there are dozens of its ilk under dev-python from which you can model the ebuild. No rush. Await reply
Created attachment 394984 [details] jenkinsapi-0.2.26.ebuild Explicit deps, Python 3.4 + pypy support.
- from $URL: the project have been tested and working on Python 2.6, 2.7 and 3.3 Do we still add Python 3.4 / PyPy? - dev-python/requests lowest version in portage is 2.3.0, do we still need to add dep on that specific version?
(In reply to Tomas Mozes from comment #5) > - from $URL: > the project have been tested and working on Python 2.6, 2.7 and 3.3 > > Do we still add Python 3.4 / PyPy? > yes. I have tested with both and as long as they work you add. > - dev-python/requests lowest version in portage is 2.3.0, do we still need > to add dep on that specific version? yes PYTHON_COMPAT correct. KEYWORDS="~amd64" just add x86, allowed for running amd64 since amd64 multilib covers x86 by its nature DEPEND="${RDEPEND} kind of wrong. Point is you'll find this in most packages however it's technically wrong. It doesn't 'break' an ebuild but it's become so commonly accepted it's mostly just blindly accepted. Here's the litmus test. Unmerge requests and pytz and then run /path/to/dev-python/jenkinsapi/ $ ebuild jenkinsapi-0.2.26.ebuild clean compile yields warning: build_py: byte-compiling is disabled, skipping. >>> Source compiled. So this proves they are NOT required for DEPEND. However, they are required to run the tests. You will therefore find most of my ebuilds have test? ( ${RDEPEND}
Created attachment 395008 [details] jenkinsapi-0.2.26.ebuild Move RDEPS to tests, grab from github to include tests
Created attachment 395010 [details] jenkinsapi-0.2.26.ebuild Obsolete old versions
Created attachment 395012 [details, diff] use_local_jenkins_war.patch
Created attachment 395014 [details] jenkinsapi-test.log Now it runs the tests against a Jenkins instance: Ran 185 tests in 274.197s Ran 185 tests in 264.206s Ran 185 tests in 259.996s Ran 185 tests in 260.409s
I have run tested and confirmed. This is very good. I'll add it later.
28 Jan 2015; Ian Delaney <idella4@gentoo.org> +files/local_jenkins_war.patch, +jenkinsapi-0.2.26.ebuild, +metadata.xml: new ebuild, written by maintainer, entered under proxy-maintainers herd, fully tested and shored up to see test phase working fully, closes bug #537346
