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

Re: Jenkings job for DHG’s all-packages

Dear Holger,

I had a quick look at the existing jobs, but did not find my way around.
But with your guidance below, I’ll try again.

Am Sonntag, den 13.04.2014, 15:07 +0200 schrieb Holger Levsen:
> 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 started with the former, but stumbled over "gitrepo" – we have stuff
in darcs. Is the Jenkings Darcs plugin installed?

If not: We plan to switch to git in the near future; maybe I’ll wait
until after that.

For now I tried to simply add the VCS commands in the my_shell
parameter, I hope that works.

So my attempt to add a job is at
but this is really stabbing in the dark: I don’t know Jenkins, nor could
I test this, and I’m confused by the many layers of abstraction there
(defaults, job-templates, projects with jobs, some string
> >  * Install cabal-install and darcs
> >  * Run "cabal update"
> what its this update used for?

Fetching metadata from hackage (the upstream package repository).

>  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?

Possibly; I don’t know the difference between a plugin and simply
issuing "darcs get" (the equivalent to "git clone") in the shell

> >  * 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.

I’ll look into that. thanks.


Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

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

Reply to: