[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Jenkings job for DHG’s all-packages

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 

> (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"


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: