# Charla debconf

## Esqueleto
- 1: Que es Salsa.CI (intro)
- Primero: que es ci y por que lo necesitamos
- Salsa.CI y su origen
- La idea del proyecto: proveer un template genérico para los proyectos/paquetes de Debian
- Que es Gitlab CI y que es un template.
- nosotros proveemos un template de ci, que se puede personalizar.
- no somos debci

- 2: Como crecio el proyecto
- Curva de adopción
- Proyectos vs tiempo.
- Cuantos equipos y maintainers importantes lo usan.
- Que % de proyectos tiene nuestro pipeline, cuantos no tienen.
- Como:
- Podemos buscar el commit en el que la config fue agregada al repositorio.
- Podemos buscar el primer pipeline que tenga los jobs nuestros
- Identificar la linea vertical
- Curva contribuciones: Hablar de como el proyecto fue creciendo en intersados y como la comunidad se sumo.
- Contribuidores acumulativo
- Commits acumulativo

- 3: Como sumarte (usando)
- Explicar como agregar salsa ci
- Explicar como agregar salsa ci en un equipo.
- Tuco (veo en la semana de acomodar y probar el codigo)
- git options -o ci.skip y [skip ci]
- Como personalizar el pipeline, cambiar jobs, buildear otros releases en el mismo pipeline
- Por ejemplo el proyecto lintian
- Que hace: build bin y source, todos los tests que tiene.
- Personalización: un poco sobre como desactivar jobs, como cambiar el release, etc

- 4: Como sumarte (contribuyendo)
- Links del pipeline

### Descartado
- ~~Promedio de fallas encontradas en el pipelines.~~
- ~~Cuantos jobs fallan~~

- ~~Relacion con el ratio de fallas en debian archive~~
- ~~Antes de pushear cuantas fallas tenían en promedio?~~
- ~~Y después?~~

Title:
- ~~What has Salsa CI improved?~~
- ~~Did Salsa CI improve any thing?~~
- Where we are with Salsa CI.
- Where is Salsa CI right now?
- ..

Summary:
Introduction on what is and how Salsa CI can ease your work.

The Salsa CI pipeline was created 2 years ago, since then the adoption has
grown a lot. Did Salsa CI make things better? Does it help anyone? We will
show you an analisys of the impact and how the project has grown.

## Extra

### otros proyectos usando nuestro CI
- kali Linux
- ALBA España

# Chamuyo.

--INA

## Intro
- Introducción, nombres ?
- Short review of what CI and Gitlab CI are, so we're all on the same page.

## What is CI
- The following definition explains pretty well what CI is:
- Continuous Integration is the practice of building and testing
each change automatically, as early as possible.
- Every time you push your changes to a repository, a previously defined set of
scripts build and test you changes and you get quick feedback.

## Slide con diagrama de branches y CI de GitLab (Queda ese slide?, creería que no)
- workflow
- When working on git repositories, the normal workflow is branching from the main
branch of the tree and commiting your changes.
- When you push your changes, CI comes and builds and tests your changes.
- If something goes wrong, you go and push again to fix the problems.
- After the changes are reviewed and approved, the proposed changes are merged into the main branch.

## Goals.
- So, what is the intention of having CI on your project?
- Main Goals.
- Detect problems before the packages are released.
- Having a good set of tests is obviously necessary for this.
- But also basic problems can some times be found when building
and testing on a different environment.
- And this is achieved with .. (next slide)
- Build and test on reproducible envs.
- These environments are shared by every contributor.
- So every change is tested on the same environment.
- But this is not the only things CI can help with.
- Side effect
- Help avoiding repetitive tasks.
- Running the same scripts over and over is error prone.
- Building and testing takes time, so sometimes we don't run some checks that we think
shoulnd't be affected.
- You can really focus on reviewing the changes.
- Easier to attract new contributors.
- Reduces the learning curve for packaging.
- You can see how the code is built and tested.
- It's easier to review contributions.
- If you trust your CI.
- Forks run all the same CI
- No need to set up an environment.
- Just forking the project allows people to reproduce the process.

## What is _Salsa_ CI?
- Debian uses a self hosted instance of Gitlab, called Salsa.
- Gitlab CI uses yaml files on the project to configure what CI does on your project.
- On any push to the repository, Gitlab will look for the yaml and start jobs according to
the contents of the file for that commit.
- Because .gitlab-ci.yml is in the repository and is version controlled, each branch or commit
can have a different definition of what CI does.
- We developed and maintain a recipe for building and testing Debian packages.
- It runs on salsa shared infrastructure.

## Salsa CI Pipeline
- Show what the pipeline looks like.
- We have 2 stages, on the first one we build the package in both binary and source-only versions.
- If both builds succeed, the test stage is executed.
- Test stage has different kind of test enabled by default.
- Each job can be customized or even disabled.
- There are some disabled-by-default jobs like aptly, check rc bugs and check missing breaks replaces.
- lists the rc bugs that are not being addressed
- Check the produced binary packages and checks if there are conflicting files
against packages that are not declared with breaks and replaces.

- It takes no longer than 7 minutes for a regular python package.

-- JOA

## The project

- Adoption
- So... We started this because we thought that was something that will help Debian. Numbers are the only way to know.
- (slide con el grafico y la linea de first commit.)
- The project has grown in usage since the first commit.
- After it, and until the project got some usability the adoption was low.
- (slide que agrega la linea de las primeras noticias)
- Is nice to see how the different efforts of the team and the maturity of the project helped with the adoption.
- After the first news some more projects started to use salsa-ci.
- (slide que agrega la linea del email a devel)
- After the first public email to the list a good number of projects adopted, also changing the growing rate.
- (slide que agrega la linea de minidebcof)
- Tin and ina give the first talks about salsa-ci on Minidebconf Hanburg, convinicing some developers to adopt the project getting an slope on the adoption.
- (slide que agrega la linea de debconf)
- But really after the talks in last Debconf the amount of projects using salsa-ci grow faster. The growing rate changed almost to the double.
- next slide with the number
- And that lead us to have today almost fortyonehundred projects using salsa-ci
- (slide que agrega un circulo alrededor de la linea vertical)
- As highlights we can see where some developers decided to use salsa-ci on all their projects.
- (slide con una barra de adoption actual, porcentaje que lo usa y porcentaje que no)
- And where some teams did that too. This was a problem beacause the trigger of more than a thousand pipelines overloaded the salsa servers. So if you intend to do that please disable the pipeline for that commit. I will show you how to do it later.
- (adoption percentage)
- So, in percetage right now almost 20 percent of project on salsa use some kind of CI and of thouse more than 70% uses SalsCI
- and that shows that it's a generic solution for most of the projects.
- An that was wath we look for.

- Contribution
- this was possible because we have a team
- (slide con el grafico completo) Contributors
- Right now the project has 35 contributors. The growt is overall constant and we hope it continous that way.

- (slide con el grafico completo) Contributions
- With more contributors the amount of contributions grown as well.
- (slide con los highlights)
- It's nice to see that we work better wen we are together

## How to use Salsa CI
- Caratula
- By default, Gitlab has a CI path set to a configuration file on the root of the project
- This doesnt work on most Debian packages because the root of the repository belongs to upstream
- and the definition will collide
- There are many ways to use the pipeline definition.
You can find about that on the project README.
We're going to cover the most flexible way, which allows customization.
- The firtst way is to set the Custom CI path to this: `recipes/debian.yml@salsa-ci-team/pipeline`
- this will use directly the definition by salsa-ci-team
- The second way is to set the Custom CI path to a local file with the includes.
- (includes)
- This allows you to customize the CI configuration.

## Adding Salsa CI to a group.
- As I say before, when adding CI to a set of projects is important to not overload the system.
- So, be nice to the system
- Creating Pipelines to hundreds of projects at the same time can cause troubles.
- 2 different ways to avoid this are available:
- make the push with the option ci.skip
- or add [ci skip] on the commit message
- Also if you are thinking on do some automatization use tuco
- This is a tool we wrote some time ago to automatize the configuration
- Needs some love, if you're going to write some script for this, first
take a look at tuco.

## DEMO

--INA

## Contributing
- We're going to have a sprint tomorrow.
- You can reach us over irc (#salsaci)
- We can help you set up CI on your packages, or answer any of your questions.