GitLab.txt

====================
Guía de GitLab by dM
====================

==========================
Como crear una GitLab Page
==========================

GitLab te permite tener una página html en un entorno de producción, basado en
algún repositorio que tengas en tu cuenta de usuario, este servicio solo permite
el despliegue de páginas html y ficheros estáticos como hojas de estilo,
javascript, jquery entre otros, lo cual significa que es ideal para mostrar
diseños de sitios web.

=========================
Habilitar una Gitlab Page
=========================

1) Entramos en algún repositorio nuestro que tenga un index.html para mostrar
como página principal.

2) Vamos a agregar un nuevo archivo al repositorio, lo podemos hacer desde la
consola de comandos o desde la interfáz, nuevo fichero que vamos a agregar a
nuestro repositorio se debe llamar .gitlab-ci.yml y su contenido sera:

pages:
  stage: deploy
  script:
  - mkdir .public
  - cp -r * .public
  - mv .public public
  artifacts:
    paths:
    - public
  only:
  - master

Hacemos un commit para guardar el nuevo archivo, subimos los cambios en el
repositorio.

3) Hay que esperar entre 2 a 5 min para que se cree la nueva página de nuestro
repositorio, luego desde la interfaz del navegador vamos a nuestro repositorio,
en el panel de la izquierda vamos a Configuración y luego a Paginas, si ya se
creo nos saldra lo siguiente en un panel:

Congratulations! Your pages are served under:

https://myuser.gitlab.io/name_my_repo

4) Ya podemos acceder a la página de GitLab de nuestro repositorio, si entramos
y da error 404 es que todavía esta procesando, intentemos 1 min después y así
hasta que esté en línea.

==========================
Guía de la wiki y markdown
==========================

Url: https://gitlab.com/help/user/markdown#wiki-specific-markdown

====================
Integración continua
====================

La integración continua (continuous integration en inglés) es una práctica de
ingeniería de software que consiste en hacer integraciones automáticas de un
proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.

Entendemos por integración la compilación y ejecución de pruebas de todo un
proyecto.

El proceso suele ser: cada cierto tiempo (horas), descargarse las fuentes desde
el control de versiones (por ejemplo CVS, Git, Subversion, Mercurial o Microsoft
Visual SourceSafe) compilarlo, ejecutar pruebas y generar informes.

Para esto suelen utilizarse aplicaciones como Solano CI, Bamboo, Pipeline,
Apache Continuum, Hudson, Jenkins, GoCD, CruiseControl o Anthill (para proyectos
Java) o CruiseControl.Net, Team Foundation Build para .Net, que se encargan de
controlar las ejecuciones, apoyadas en otras herramientas como Ant o Maven
(también para proyectos Java), o Nant o MSBUILD (para .Net) que se encargan de
realizar las compilaciones, ejecutar las pruebas y realizar los informes.

A menudo la integración continua está asociada con las metodologías de
programación extrema y desarrollo ágil.

Ventajas
========

-Los desarrolladores pueden detectar y solucionar problemas de integración de
forma continua, evitando el caos de última hora cuando se acercan las fechas de
entrega.

-Disponibilidad constante de una versión para pruebas, demos o lanzamientos
anticipados.

-Ejecución inmediata de las pruebas unitarias.

-Monitorización continua de las métricas de calidad del proyecto.

Fuentes
=======

-https://es.wikipedia.org/wiki/Integraci%C3%B3n_continua

=====
CI/CD
=====

En ingeniería de software, CI/CD o CICD generalmente refiere a las prácticas
combinadas de integración continua y entrega continua (también conocida como
despliegue continuo).

Contamos con herramientas para esto en GitLab por ejemplo.

Fuentes
=======

-https://es.wikipedia.org/wiki/CI/CD

================
Entrega continua
================

Entrega continua (continuous delivery en inglés) es un enfoque de la ingeniería
del software en que los equipos de desarrollo producen software en ciclos
cortos, asegurando que el software puede ser liberado en cualquier momento, de
forma confiable.

Apunta a la construcción, prueba, y liberación del software de forma más rápida
y más frecuente. Este enfoque ayuda en la reducción del costo, tiempo, y riesgo
de la liberación de versiones a través de la liberación de versiones más
incrementales a aplicaciones en producción. Un proceso directo y repetible de
liberación es importante para una entrega continua.

Etapas
======

-Automatización de la compilación e integración continua: Esta etapa consta de
la creación de archivos binarios a partir del código fuente. A medida que los
desarrolladores implementan nuevas funciones, estas son integradas al código
central, compiladas, y probadas.

-Automatización de pruebas: En esta etapa se prueba rigurosamente la nueva
versión de aplicación, para asegurar que cumple con todos los requerimientos de
calidad del sistema.

-Automatización de implementación: Luego que las etapas anteriores fueron
verificadas, se puede implementar la nueva versión en el ambiente de producción.

Esta implementación se realiza de forma automática, dejando disponibles las
nuevas funcionalidades al usuario, en solo unos minutos.

Fuentes
=======

-https://es.wikipedia.org/wiki/Entrega_continua

=================================================================
Cómo recibir notificaciones del repositorio de GitLab en Telegram
=================================================================

1) Añadimos como participante del grupo a @gitlab_bot, este último dejo de
funcionar por lo cual está la opción de añadir a @GitLabX_BOT que es lo mismo.

2) Al agregarlo al grupo, llega un mensaje como este:

Hi here! To setup notifications for this chat your GitLab project(repo), open
Settings -> Web Hooks and add this URL:
https://integram.org/gitlab/cQgO-Szntu4

ó

Hi here! To setup notifications for this chat your GitLab project(repo),
open Settings -> Web Hooks and add this URL:
http://lab6.btech.id:9876/gitlab/cAVLqxuHaZ4

3) Nos vamos al repositorio de Gitlab, nos vamos a la parte cd Configuración >
Webhooks y en el campo url pegamos la url que nos pasó el bot por el chat de
telegram.

4) Le damos click a Add webhook y listo, ya solo resta probar algún eventos
para verificar que esté funcionando.

========================
El archivo gitlab-ci.yml
========================

El archivo .gitlab-ci.yml sirve para configurar el comportamiento de Gitlab CI
en cada proyecto. En el archivo define la estructura y el orden de los pipelines
y determina qué ejecutar con el Gitlab runner y qué decisiones tomar cuando
condiciones específicas se cumplen (como cuando un proceso falla o termina
exitosamente).

Fuente
======

https://platzi.com/clases/1526-gitlab/19299-gitlab-ciyml/

================================
Caso casi práctico GitlLab CI/CD
================================

Vamos a suponer que tenemos un API de Node que trae una lista de libros de una
base de datos. Un escenario bastante sencillo y práctico, para no complicar
mucho las cosas.

A partir de ahora, podemos crear una tubería (pipeline a partir de ahora), que
empuje nuestro código en 3 fases: construcción, pruebas y entrega. Recordemos
que un pipeline es un grupo de pasos que son agrupados bajo características
similares. Con estas fases o etapas, nuestro pipeline es definido en 3 tipos:

1: El Pipeline del proyecto (Project Pipeline).
2: El Pipeline de integración continua.
3: El Pipeline de entrega.

El pipeline del proyecto instala dependencias, corre los linters y cualquier
script que tenga que ver con código. El pipeline de integración continua corre
pruebas automatizadas y construye versiones distribuidas del código.

Finalmente, el pipeline de entrega, entrega el código a un ambiente de un
proveedor de nube designado.

El esquema resultante resumido sería el siguiente:

A) Build
  i. Install NPM Dependencies
  ii. Run ES-Linter
  iii. Run Code-Minifier
B) Test
  i. Run unit
  ii. Run compile
C) Deploy
  i. Production
    1) Launch EC2 instance on AWS
  ii. Staging
  iii.
    1) Launch on local development server

En esta jerarquía, los tres componentes son considerados tres diferentes
pipelines. Las partes importantes (build, test y deploy) son etapas (stages) y
cada parte debajo de estas secciones son trabajos.

Para usar GitLab CI/CD, creamos un archivo con nombre “.gitlab-ci.yml” en la
raíz del proyecto de nuestro repositorio de GitLab y agregamos el siguiente
código yaml:

image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_scripts
  - npm install

Todo lo anterior es un ejemplo, simplemente el archivo describe instrucciones
para ejecutar de manera secuencial.

Fuente
======

https://www.icm.es/2020/07/17/caso-practico-gitlab-ci-cd/

=======================================================================
Recibir notificaciones en telegram de las acciones de un repo con CI/CD
=======================================================================

1- Primero debes crear un nuevo bot. Abre Telegram y busca el bot "BotFather".

2- Inicia una conversación con BotFather y envíale el comando "/newbot".

3- Sigue las instrucciones que te dará BotFather. Primero, debes proporcionarle
un nombre para tu bot. Luego, debes proporcionarle un nombre de usuario que
termine en "bot". Por ejemplo, "myawesomebot".

BotFather te proporcionará un token de acceso para tu bot. Guárdalo en un lugar
seguro, ya que lo necesitarás más adelante para enviar solicitudes a la API de
Telegram.

Ejemplo:

Ya estando en el chat con BotFather, escribimos

/newbot

BotFather:

Alright, a new bot. How are we going to call it? Please choose a name for your bot.

prueba

BotFather:

Good. Now let's choose a username for your bot. It must end in `bot`. Like this,
for example: TetrisBot or tetris_bot.

pruebabot

BotFather:

Done! Congratulations on your new bot. You will find it at t.me/pruebabot. You
can now add a description, about section and profile picture for your bot, see
/help for a list of commands. By the way, when you've finished creating your
cool bot, ping our Bot Support if you want a better username for it. Just make
sure the bot is fully operational before you do this.

Use this token to access the HTTP API:
xxxxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Keep your token secure and store it safely, it can be used by anyone to control
your bot.

For a description of the Bot API, see this page: https://core.telegram.org/bots/api

-----

¡Listo! Ahora tienes un bot de Telegram. Puedes usar el token de acceso para
enviar solicitudes a la API de Telegram y crear las funcionalidades que deseas
para tu bot. Por ejemplo, puedes configurar el bot para enviar mensajes
automáticos, responder a comandos o interactuar con otros usuarios de Telegram.

4- Ahora debemos obtener el id que es único único de un grupo o canal en el cual
queremos recibir las notificaciones, para obtenerlo agregue temporalmente el bot
https://telegram.me/itpp_myid_bot al grupo o canal, este te devolvera el id del
grupo. normalmente, es un entero negativo.

5- Ahora vamos al repo que queremos que notifique cuando tenga interacciones Y
creamos en la raíz un archivo con nombre .gitlab-ci.yml, el contenido de ese
archivo será:

-----

stages:
  - notify

telegram_notification:
  stage: notify
  image: curlimages/curl:latest
  script:
    - export MESSAGE="Se ha realizado un nuevo push, el mensaje del commit es: '$CI_COMMIT_MESSAGE'"
    - curl -s -X POST https://api.telegram.org/botTELEGRAM_TOKEN/sendMessage -d chat_id=XXXX -d text="${MESSAGE}" >> /dev/null
  only:
    - master

-----

Donde secrets.TELEGRAM_TOKEN es el token secreto de tu bot y
XXXX es el id del chat que te dio el bot itpp_myid_bot.

Para probarlo, simplemente hacemos un nuevo push al repositorio y este nos
debería notificar en telegram.

Desde la sección pipelines de nuestro repositorio podremos ver las ejecuciones
realizadas del archivo .gitlab-ci.yml.

Con más detalles:

stages:
  - notify

telegram_notification:
  stage: notify
  image: curlimages/curl:latest
  script:
    - export MESSAGE="Nuevo push a la rama: $CI_COMMIT_REF_NAME, commit '$CI_COMMIT_MESSAGE' > $CI_PROJECT_URL/-/commit/$CI_COMMIT_SHA"
    - curl -s -X POST https://api.telegram.org/botXXXX/sendMessage -d chat_id=XXXX -d text="${MESSAGE}" >> /dev/null
  only:
    - master

Crear variables en nuestro repositorio para CI/CD
==================================================

Configurtación > CI/CD > Variables > Añadir variable, agregamos una nueva con
clave: BotTELEGRAM_TOKEN y valor, el token de nuestro bot.

Para utilizar la variable BotTELEGRAM_TOKEN en la línea de comando que mencionas
debes sustituir <your_bot_token> por $BotTELEGRAM_TOKEN, de la siguiente manera:

- curl -s -X POST https://api.telegram.org/bot$BotTELEGRAM_TOKEN/sendMessage -d chat_id=<your_chat_id> -d text="${MESSAGE}" >> /dev/null

De esta forma, la variable BotTELEGRAM_TOKEN se expandirá en su valor
correspondiente en la línea de comando.

Recuerda que para que esto funcione, debes haber definido previamente la
variable BotTELEGRAM_TOKEN en tu archivo .gitlab-ci.yml o en la sección
"Variables" de tu proyecto en GitLab, tal como lo hemos mencionado
anteriormente.

Lo mismo se puede hacer con el ID del chat, declarar la variable CHAT_ID, agregar
su valor con usarla en el comando con $CHAT_ID.

Ahora agregamos el autor del commit y también que notifique de cambios en la
rama dev:

stages:
  - notify

telegram_notification:
  stage: notify
  image: curlimages/curl:latest
  script:
    - export MESSAGE="Nuevo push de $CI_COMMIT_AUTHOR en la rama $CI_COMMIT_REF_NAME, commit '$CI_COMMIT_MESSAGE' > $CI_PROJECT_URL/-/commit/$CI_COMMIT_SHA"
    - curl -s -X POST https://api.telegram.org/bot$BotTELEGRAM_TOKEN/sendMessage -d chat_id=$CHAT_ID -d text="${MESSAGE}" >> /dev/null
  only:
    - master
    - dev

Para que notifique los cambios de dev o de cualquier otra rama esta debe ser una
rama protegida.

-----

Obteniendo solo el Nombre y Apellido del auto y no el correo:

stages:
  - notify

telegram_notification:
  stage: notify
  image: curlimages/curl:latest
  script:
    - export MESSAGE="Nuevo push en el repo $CI_PROJECT_URL de $(echo $CI_COMMIT_AUTHOR | cut -d' ' -f1,2) en la rama $CI_COMMIT_REF_NAME, commit $CI_COMMIT_MESSAGE -> $CI_PROJECT_URL/-/commit/$CI_COMMIT_SHA"
    - curl -s -X POST https://api.telegram.org/bot$BotTELEGRAM_TOKEN/sendMessage -d chat_id=$CHAT_ID -d text="${MESSAGE}" >> /dev/null
  only:
    - master

Recomendada:

telegram_notification:
  stage: notify
  image: curlimages/curl:latest
  script:
    - export MESSAGE="$(echo $CI_COMMIT_AUTHOR | cut -d' ' -f1,2) pusheo a la rama $CI_COMMIT_REF_NAME | $CI_COMMIT_MESSAGE -> $CI_PROJECT_URL/-/commit/$CI_COMMIT_SHA"
    - curl -s -X POST https://api.telegram.org/bot$BotTELEGRAM_TOKEN/sendMessage -d chat_id=$CHAT_ID -d text="${MESSAGE}" >> /dev/null
  only:
    - master

========================
Rama protegida en GitLab
========================

Una rama protegida en GitLab es una rama en un repositorio de Git que ha sido
configurada para tener restricciones adicionales para evitar cambios no
autorizados. Esta configuración se implementa para prevenir modificaciones
accidentales o no autorizadas en ramas importantes del repositorio, como la rama
"master" o ramas de desarrollo principales.

Cuando una rama está protegida en GitLab, se aplican ciertas restricciones y
reglas que generalmente incluyen:

No permitir push directo: Los usuarios no pueden hacer push directamente a la
rama protegida. Los cambios deben enviarse mediante merge requests (también
conocidos como "pull requests" en otros sistemas de control de versiones).

Revisión de cambios (Code Review): Antes de que los cambios se incorporen a la
rama protegida, al menos una revisión de código (code review) aprobada es
necesaria. Otros miembros del equipo deben revisar y aprobar los cambios antes
de que se fusionen con la rama protegida.

Requerir pipelines exitosos: Antes de que los cambios se fusionen con la rama
protegida, se exige que los pipelines de CI/CD sean exitosos. Esto garantiza que
los cambios cumplan con las pruebas automatizadas antes de integrarlos en la
rama protegida.

Restricciones adicionales: GitLab permite configurar restricciones adicionales
según las necesidades del proyecto, como requerir que solo ciertos usuarios o
grupos tengan permiso para aprobar merge requests en la rama protegida.

Las ramas protegidas en GitLab son una medida de seguridad importante para
garantizar la calidad y la integridad del código en el repositorio. Al
restringir la posibilidad de cambios directos en ramas importantes, se minimiza
el riesgo de errores y problemas en el código base, y se fomenta un enfoque
colaborativo a través de revisiones y pruebas antes de la incorporación de
cambios a la rama principal del repositorio.

Fuente
======

ChatGPT

============================================================================
Hacer push a un repositorio gitlab pasando usuario y contraseña directamente
============================================================================

$ git push https://your-username:your-token@gitlab.com/usuario/repositorio.git master

Ejemplo:

$ git push https://pepeperez:xyz1233212zyx@gitlab.com/pepeperez/mi_repo.git master

Fuente
======

ChatGPT