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

Re: Debian CI pipeline for Developers




El 15/11/18 a las 16:00, Leopold Palomo-Avellaneda escribió:
Hi Inaki,

El 15/11/18 a les 18:04, Inaki Malerba ha escrit:

[...]

- 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`[1] keyword to filter the branches and have
different pipelines depending on the branch name. It would look
something like this:

```
[..]
build unstable:
    extends: .build-unstable
    except:
        - /^stretch-.*$/

build stretch:
    extends: .build-stretch
    only:
        - /^stretch-.*$/
```

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.

Sorry if I made stupid questions, but should I have yaml file in all the
branches?

That's right.

On Gitlab CI the pipeline is defined on the project itself, in contrast to other systems like Jenkins where the pipeline is defined for the whole project. Because of this, you need to have the recipe on all the branches you want to run CI on.

From the Gitlab CI doc[0]:

> Because .gitlab-ci.yml is in the repository and is version controlled, old versions still build successfully, forks can easily make use of CI, branches can have different pipelines and jobs, and you have a single source of truth for CI.

If I'm not being clear enough, I recommend you to read [0] and [1].
I'm sorry if I insist because from my point of view is not an obvious
procedure and it could be very useful.

Please, don't hesitate on asking all the things that aren't clear :)


0_ https://docs.gitlab.com/ee/ci/quick_start/README.html
1_ https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
-- 
- ina

Reply to: