Re: Debian CI pipeline for Developers
- Date: Thu, 15 Nov 2018 14:04:53 -0300
- From: Inaki Malerba <email@example.com>
- Subject: Re: Debian CI pipeline for Developers
El 15/11/18 a las 11:14, Leopold Palomo-Avellaneda escribió:
> El 10/11/18 a les 21:05, Agustin Henze ha escrit:
>> Hello everyone, on behalf the salsa-ci-team we would like to spread the word
>> about the Continuous Integration pipeline we have created for Debian
>> The main idea is to have faster feedback when you are working in a package if
>> it has the quality needed to be part of the Debian archive. The tests we got
>> working so far, are the following:
>> * Building the package from the source (only gbp is supported for now)
>> * Lintian check
>> * Reproducible build (Using reprotest)
>> * piuparts
>> * Autopkgtest
>> Please follow the README to enable CI in your packages.
>>  https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
> I don't know if it's the correct place but I have some issues about this.
> - I have not be able to set up directly a gitlab-ci.yaml directly in a debian
> directory. If I define it as the document says, I cannot activate the CI.
> However if I activate first in the root directory then I can activate the
> pipeline and after I can move it to the debian directory.
You can find information about that on the pipeline readme. The
default path is in the root of the repo, but it can be changed on the
> - I can only make CI with the master branch (or I don't know how to do it in
> other branches). How can I activate it in other branches differents than master?
How did you define the yaml? If you use the one on the example, it
should run on every pipeline. Maybe you should rebase the branches?
> - Can I set a CI yaml file different by branch? one for unstable, one for
> stable, etc?
We decided that the provided example is the easiest way to run. On the
branches for other releases, ej. backports, you should modify the
`expand` key to build for a different debian release.
Another possibility is to create more than one build job on the yaml
file and use the `only` keyword to filter the branches and have
different pipelines depending on the branch name. It would look
something like this:
This example is only illustrative. Using that, `build unstable` would
run on all the branches except those whose name starts with `stretch-`,
where `build stretch` will be triggered.
> In any case, thanks for the work done. It's really good.
Hope that helped,