Hi Joachim, sorry that it took me so long for the initial reply. If nothing comes in the way, followup replies will be *much* faster.
On Sonntag, 9. März 2014, Joachim Breitner wrote: > the Haskell team maintains a list of haskell package versions that we > are distributing (or plan to distributing), and we have a script that > verifies that, judging from the Haskell package metadata, there is a > chance that this combination works. > > It would be great if this check would run regularly in a jenkins job, > and notify us about failures. I'd be very happy to have this running on jenkins.d.n *and* you supplying+maintaining the needed job configuration to do so :-) There are two reasonable good examples for this, which you can use as a base. git clone ssh://git.debian.org/git/qa/jenkins.debian.net.git and then have a look at job-cfg/lintian-tests.yaml and job-cfg/rebootstrap.yaml - they both run commands in a (throwaway) chroot, the lintian jobs also install the build- depends from debian/control, but you could equally run "apt-get install foo" in a custom script. I'd *really really* would like you to prepare a git repo with some branch from which I could pull. That's *way* better than me writing this job definition and updating based on your descriptions. Just send me pull requests and I happily merge them. Also and esp. to fix trivial things :) > The job should do this: > * Enter an unstable or testing chroot, easy, see the shell command in those yaml files and then put the following in one script, or maybe not... > * Install cabal-install and darcs > * Run "cabal update" what its this update used for? or asked differently, shouldn't I install the darcs plugin for jenkins and then your job could checkout that darcs repo like the other jobs checkout their git repo? > * Run "darcs get http://anonscm.debian.org/darcs/pkg-haskell/tools/"; > * Run "cd tool/all-packages" > * Run "./test-packages" > * Fail depending on that scripts error code. the job will fail automatically if the exit code aint 0. You can also use logparser rules (see ./logparser in the jenkins.d.n git repo) to make the job fail (or become "unstable", which is in between failure+ok) based on parsed output. > (May need some tweaking, i.e. more dependencies, but you get the idea). see above. please tweak it yourself :) > Can someone help me write a jenkins job for that? I hope this is a good start, if not, please do ask. Also feel free to ask on #debian-qa, there are a lot of jenkins.d.n discussions atm :) > I looked at ruby-qa.yaml, but I could not find where to install > dependencies (like darcs or cabal-install). Or does jenking’s chroot > already have ruby installed? I think ruby is installed yes. But inside the chroot you are root or you could do as lintian-tests.yaml does and use build-depends and use "debuild runtests" cheers, Holger
signature.asc
Description: This is a digitally signed message part.
