Git Actions de GitHub (Parte 5)

Continuamos con algún ejemplo de GitHub Action

workflow.yml: Cuando se crea una rama nueva se modifica en ella la versión del pom.xml, añadiéndole un sufijo extraido del nombre de dicha rama.

name: On create branch - Rename version pom.xml
# Esta action se va a ejecutar cada vez que se crea una rama de main
on:
  create:
    branches:
      - main
jobs:
  # Tarea que se encargar de sacar el sufijo de la rama
  extract-suffix-name-branch:
      runs-on: ubuntu-latest
      #Lista de variables de salida del job
      outputs:
        suffix_name: ${{ steps.get-id.outputs.id }}
      steps:
        # Checkout repository
        - uses: actions/checkout@v2         
          
        # Utilizamos action que recupera los nombres de las ramas las ramas 
        - name: Get branch name
          id: branch-name
          uses: tj-actions/branch-names@v5.1
          
        # Mostramos por pantalla el nombre de la rama actual: 'prueba-100] description rama'
        - name: Running on the default branch.
          if: steps.branch-name.outputs.is_default == 'true'
          run: |
            echo "Running on default: ${{ steps.branch-name.outputs.current_branch }}"
        # Extraemos el sufijo que queremos utilizar para la version del pom: 'prueba-100'
        - id: get-id
          run: |
            id=$(echo ${{ steps.branch-name.outputs.current_branch }} | cut -d] -f1 | cut -d[ -f2)
            echo "::set-output name=id::$id"

  # Tarea que se encargar de sacar el prefijo de la versión del pom.xml  
  extract-preffix-name-pom-version:
      runs-on: ubuntu-latest
      #Lista de variables de salida del job
      outputs:
        preffix_name: ${{ steps.get-id.outputs.id }}
      steps:
        # Checkout repository
        - uses: actions/checkout@v2        
                
        #Tarea extrae a la variable version, la version existente en el pom.xml
        - name: Extract Maven project version
          working-directory: ./example3-gitactions
          run: echo ::set-output name=version::$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)
          id: project_version
        - run: echo "Maven project version is ${{ steps.project_version.outputs.version }}"

        - id: get-id
          run: |
            id=$(echo ${{ steps.project_version.outputs.version }} | cut -d- -f1)
            echo "::set-output name=id::$id"       

  # Tarea que se encargar modificar la versión del pom.xml  
  rename-pom-version-and-commit:
      # Se le indica que depende de las dos tareas anteriores
      needs: [extract-preffix-name-pom-version, extract-suffix-name-branch]
      runs-on: ubuntu-latest
      steps:
        # Checkout repository
        - uses: actions/checkout@v2          
        
        # Instalamos jdk 11
        - name: Set up JDK 1.11
          uses: actions/setup-java@v1
          with:
            java-version: 1.11             
              
        # Realiza la modificación de la versión del pom.xml. 
        # Indicando generateBackupPoms a true nos generaría un backup del pom.xml que podríamos utilizar para restaurarlo al mergear la pull-request.
        - name: set version pom
          working-directory: ./example3-gitactions
          run: mvn -B versions:set -DnewVersion=${{ needs.extract-preffix-name-pom-version.outputs.preffix_name }}-${{ needs.extract-suffix-name-branch.outputs.suffix_name }}-SNAPSHOT -DgenerateBackupPoms=false

         # Realiza una prueba de que sigue compilando perfectamente. 
        - name: mvn package
          run: mvn -B package --file example3-gitactions/pom.xml
          
        # Subimos el cambio al repo. 
        - name: Commit new version pom.xml - branch
          run: |
            git config --global user.name 'Roberto'
            git config --global user.email 'roberto-pf@github.com'
            git add .
            git commit -am "Automated report"
            git push

Nota: Repositorio Github

Documentación action que extrae el nombre de la rama: tj-actions/branch-names

Git Actions de GitHub (Parte 3)

Continuamos con algún ejemplo de GitHub Action

workflow-external_json_parameters.yml: Contiene dos jobs para extraer la información de un json. El primer job utiliza JQ y el segundo es más simple ya que el json está en una única línea.

name: Read External JSON
//Evento que desencadenará el workflow
on: [push]
jobs:
  //Primer job a ejecutar 
  read-json-with-jq:
      //Máquina en la que se va a ejecutar el job 
      runs-on: ubuntu-latest
      steps:
        //Tarea que hace un checkout del repositorio
        - uses: actions/checkout@v2

        - name: extract repositories to file
          run: |
            //se vuelca a la variable content el contenido del fichero json
            content=`cat ./example2-gitactions/dependencies.json`
            //con JQ extraemos todos los valores de la key repository y los listamos en un fichero txt
            echo "$(jq -r '.dependencies[].repository' <<< "$content")" >> aux.txt
        //Tarea que pinta por pantalla los repositorios
        - name: print repositories
          run: cat aux.txt

  //Segundo job a ejecutar
  read-json: 
       //Máquina en la que se va a ejecutar el job 
       runs-on: ubuntu-latest
       steps:
        //Tarea que hace un checkout del repositorio
        - uses: actions/checkout@v2
        
        - name: extract repositories to array
          id: set_var
          run: |
            //se vuelca a la variable content el contenido del fichero json
            content=`cat ./example2-gitactions/dependencies-one-line.json`
            //se setea como salida en la variable jsonDep
            echo "::set-output name=jsonDep::$content"
        //Tarea que pinta por pantalla los repositorios
        - name: print repositories
          run: |
            echo: "${{fromJson(steps.set_var.outputs.jsonDep).dependencies[0].repository}}"
            echo: "${{fromJson(steps.set_var.outputs.jsonDep).dependencies[1].repository}}"

Nota: Repositorio Github

Git Actions de GitHub (Parte 2)

Continuamos con algún ejemplo de GitHub Action

3 – get version from pom workflow.yml: un job extrae la version del pom para que se utilice tanto en otros jobs como en steps posteriores.

//Nombre del workflow
name: Get version from pom.xml
//Evento que desencadenará el workflow
on: [push]
//Configuración por defecto.
defaults:
    run:
        //Se indica el directorio desde donde se ejecutarán los jobs.
        working-directory: example1-gitactions
//lista de trabajos a realizar
jobs:
    //Job a ejecutar 
    get-version:
        //Máquina en la que se va a ejecutar el job 
        runs-on: ubuntu-latest
        //Lista de variables de salida del job
        outputs:
            output_version: ${{ steps.project_version.outputs.version }}     
        //Lista de steps/tareas a realizar dentro del job 
        steps:
            //Tarea que hace un checkout del repositorio
            - uses: actions/checkout@v2
            //Tarea que instala en la máquina java 11
            - name: Set up JDK 1.11
              uses: actions/setup-java@v1
              with:
                java-version: 1.11
            //Tarea extrae a la variable version, la version existente en el pom.xml
            - name: Extract Maven project version
              run: echo ::set-output name=version::$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)
              //identificador asignado a la tarea
              id: project_version
            //Tarea que hace un echo de la variable creada en la tarea anterior
            - name: Show extracted  Maven project version
              run: echo "Version is ${{ steps.project_version.outputs.version }}"
    //Job a ejecutar   
    use-version:
        //Se indica que este job va a depender del anterior. Es decir, se va a ejecutar el otro primero.
        needs: get-version
        //Máquina en la que se va a ejecutar el job 
        runs-on: ubuntu-latest
        //Lista de steps/tareas a realizar dentro del job
        steps:
            //Tarea que hace un checkout del repositorio
            - uses: actions/checkout@v2
            //Tarea que hace un echo de la variable creada en el job anterior
            - name: Show extracted  Maven project version
              run: echo "Version is ${{ needs.get-version.outputs.output_version }}"

4 – env get version from pom workflow.yml: en un job se estrae la version del pom y la mete en el environment. Se puede ver como se puede utlizar en los steps posteriores pero no en otros jobs

//Nombre del workflow
name: Get version from pom.xml - env
 //Evento que desencadenará el workflow
on: [push]
//Configuración por defecto.
defaults:
 run:
  //Se indica el directorio desde donde se ejecutarán los jobs.
  working-directory: example1-gitactions
//lista de variables de entorno inicializadas para usar en los jobs
env: 
  GITHUB_RELEASE_VERSION: "prueba"
  
//lista de trabajos a realizar
jobs:
 //Job a ejecutar 
 get-version-env:
    //Máquina en la que se va a ejecutar el job 
    runs-on: ubuntu-latest
    //Lista de steps/tareas a realizar dentro del job 
    steps:
      //Tarea que hace un checkout del repositorio
      - uses: actions/checkout@v2
      //Tarea que instala en la máquina java 11
      - name: Set up JDK 1.11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      //Tarea extrae a la variable de entorno GITHUB_RELEASE_VERSION, la version existente en el pom.xml
      - name: Extract Maven project version
        run: echo "GITHUB_RELEASE_VERSION=$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)" >> $GITHUB_ENV
      //Tarea que hace un echo de la variable de entorno GITHUB_RELEASE_VERSION. Mostrará el valor de la version del pom
      - name: Show extracted  Maven project version
        run: echo "Version is ${{ env.GITHUB_RELEASE_VERSION }}"
 //Job a ejecutar 
 use-version:
    //Se indica que este job va a depender del anterior. Es decir, se va a ejecutar el otro primero.
    needs: get-version-env
    //Máquina en la que se va a ejecutar el job 
    runs-on: ubuntu-latest
    //Lista de steps/tareas a realizar dentro del job 
    steps:
      //Tarea que hace un checkout del repositorio
      - uses: actions/checkout@v2
      //Tarea que instala en la máquina java 11
      - name: Set up JDK 1.11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      //Tarea que hace un echo de la variable de entorno GITHUB_RELEASE_VERSION. Mostrará el valor por defecto "prueba"
      - name: Show extracted  Maven project version
        run: echo "Version is ${{ env.GITHUB_RELEASE_VERSION }}"

Nota: Repositorio Github

Git Actions de GitHub (Parte 1)

Las GitHub Actions te permiten automatizar tareas en tu proyecto: despliegues, ejecución de test,… Se dispone de múltiples acciones en el Marketplace de GitHub que se pueden utilizar. Si bien, también se puede desarrollar acciones propias.

Para crearlas es tan sencillo como crear el directorio .github/workflows/ en tu repositorio y dentro de dicho directorio se colocarían los ficheros yml que contienen las actions.

Para probar su funcionamiento me he creado un proyecto sencillo en GitHub y le he añadido las siguientes actions:

1 – echo example workflow.yml: Ejecuta el comando echo

//Nombre del workflow
name: Execute echo command
//Evento que desencadenará el workflow
on: [push]
//lista de trabajos a realizar
jobs:
 //Job a ejecutar
 echo:
   //Máquina en la que se va a ejecutar el job 
   runs-on: ubuntu-latest
   //Lista de steps/tareas a realizar dentro del job
   steps:
     //Tarea a ejecutar. Tiene un name con la descripción y un run con el comando a ejecutar.
     - name: test echo
       run: echo "Testing echo"

Ejemplo Git Action 1

2 – mvn example workflow.yml: Ejecuta un mvn package

//Nombre del workflow
name: Build and test of Java Project
//Evento que desencadenará el workflow
on: [push]
//Configuración por defecto.
defaults:
 run:
  //Se indica el directorio desde donde se ejecutarán los jobs.
  working-directory: example1-gitactions
//lista de trabajos a realizar
jobs:
 //Job a ejecutar
 build:
   //Máquina en la que se va a ejecutar el job 
   runs-on: ubuntu-latest
   //Lista de steps/tareas a realizar dentro del job
   steps:
     //Tarea que hace un checkout del repositorio
     - uses: actions/checkout@v2
     //Tarea que instala en la máquina java 11
     - name: Set up JDK 1.11
       uses: actions/setup-java@v1
       with:
         java-version: 1.11
     //tarea que ejecuta un mvn package
     - name: Build with Maven
       run: mvn -B package --file pom.xml

Nota: Repositorio Github

Configuración de una ssh-key para Github desde ubuntu.

A modo de guía, para configurar una ssh-key en ubuntu y poder conectarnos a nuestra cuenta de GitHub habría que seguir los siguiente pasos:

– Paso 1 / Ejecutar el comando

ssh-keygen -t rsa

– Paso 2 / Te preguntará donde quieres dejar la clave

Enter file in which to save the key (/home/rober/.ssh/id_rsa):

– Paso 3 / Te pedirá que introduzcas una frase de seguridad

Enter passphrase (empty for no passphrase):

– Paso 4 / Si todo ha ido bien te va a generar estos dos ficheros

Your identification has been saved in /home/rober/.ssh/id_rsa
Your public key has been saved in /home/rober/.ssh/id_rsa.pub

– Paso 5 / Ahora que ya tenemos la clave nos vamos a GitHub.com en: Acount Settings -> SSG and GPG Keys -> New SSH Key

– Paso 6 / Nos pedirá que rellenemos dos campos en un formulario:

Title: Se puede poner uno descriptivo para saber desde donde se está usando esa clave.
key: Se pega el contenido del fichero /home/rober/.ssh/id_rsa.pub

– Paso 7 / Dar a Add SSH Key. Y ya podremos conectarnos a la cuenta de github desde la máquina en que hemos configurado la clave.

Nota: Para cargar en la clave privada en un terminal seria usando el comando ssh-add.
ssh-add /home/rober/.ssh/id_rsa

Nota 2: Comandos para configurar tu usuario

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Git – Manejo de ramas con rebase

1/ Creamos un repositorio de trabajo local vacío, llamado prueba.

git init prueba

2/ Ahora dentro del directorio prueba que se nos ha creado podemos ir añadiendo nuestros ficheros de código.

3/ Creamos una rama prueba_rama y realiza el checkout dicha rama.

git checkout -b prueba_rama < commit_id >

4/ añadimos commits a esa rama.

5/ Ahora podemos realizar el merge entre las dos ramas. Por ejemplo, situados en la rama prueba_rama le integramos con el rebase la master:

git checkout prueba_rama
//Realiza el rebase 
git rebase master
//si  hay conflictos debemos resolverlos y luego dar a continuar el rebase.
git rebase --continue

6/ Por último vamos a añadir un commit a la master con lo que tenemos en la rama. Para ello, situados en la rama master ejecutamos el merge:

git checkout master
//Realiza el rebase 
git rebase prueba_rama

Git – Problema acceso denegado.

Suele pasar cuando se tienen varias cuentas distintas.

Si al intentar acceder a una cuenta remota de Git (ya sea en github u otro sitio) nos da error de acceso denegado podemos solucionarlo así:

git config --global --edit

Y añadir estas líneas de configuración al final de fichero.

[credential]
helper = osxkeychain
useHttpPath = true

Git – Manejo de ramas con merge

1/ Creamos un repositorio de trabajo local vacío, llamado prueba.

git init prueba

2/ Ahora dentro del directorio prueba que se nos ha creado podemos ir añadiendo nuestros ficheros de código. Tenemos un par de comandos interesantes que podemos utilizar:

//Conocer el estado de los ficheros
git status
//Ver el histórico de commits
git log --oneline
//Muestra las diferencias con el commit anterior
git diff  < commit_id1 >   < commit_id2 >

3/ Creamos una rama prueba_rama y realiza el checkout dicha rama.

git checkout -b prueba_rama < commit_id >
//subir la rama al repositorio remoto
git push --set-upstream origin prueba_rama
//Podemos ver la ramas existentes
git branch -v
//Muestra el histórico de todas las ramas.
git log --oneline --all

4/ añadimos commits a esa rama.

5/ Ahora podemos realizar el merge entre las dos ramas. Por ejemplo, situados en la rama prueba_rama le integramos con el merge la master:

git checkout prueba_rama
//Realiza el merge
git merge master
//si  hay conflictos debemos resolverlos y luego dar a continuar el merge.
git merge --continue
//Deshace el merge en curso, útil si hay conflictos.
git merge --abort
//Muestra la historia de integraciones de todas las ramas.
git log --oneline --graph --all

6/ Por último vamos a añadir un commit a la master con lo que tenemos en la rama. Para ello, situados en la rama master ejecutamos el merge:

git checkout master
//Realiza el merge
git merge prueba_rama

Git para Dummies

Esta guia puede ser útil para la gente que esté empezando con GIT. Es una forma sencilla de trabajar con git en tus inicios hasta que domines la resolución de conflictos. Para ello vamos a necesitar el Git Bash y otra herramienta como es el Beyond Compare.

Desde el Git Bash clonamos el repositorio a tratar. Por ejemplo lo podemos clonar a un directorio que se llame REPO_APP.

//Comando para clonar un repositorio
git clone https://user@gitlab.es/app/telxius/integration/aaaa.git 

Una vez clonado copiamos el mismo directorio a otro sitio de tu pc y lo llamamos REPO_APP2. La idea es trabajar contra este directorio, de tal forma que contenga todos nuestros cambios.
Cuando queramos subir esos cambios al repositorio local la forma en que podriamos proceder es la siguiente:

1/ Te descargas todos los cambios del repositorio remoto a REPO_APP

//Comando para descargarte los cambios
git pull

2/ Utilizas el Beyond Compare para pasar tus cambios de REPO_APP2 a REPO_APP. También deberás pasar de REPO_APP a REPO_APP2 las actualizaciones que se hayan descargado.

3/ Subes los cambios que ahora tienes en REPO_APP.

//Comandos para subir cambios
git add .       <---Registra tus cambios
git commit      <---Este hace el commit en tu repositorio local
git push        <---Este sube el commit al repositorio remoto

ADICIONAL

//Comando para resetear todos tus cambios y volver a cargar los del master.
git reset --hard origin/master

Comandos para crear etiquetas (ya que te puede ser interesante crear una etiqueta antes de subir un evolutivo grande, lo recomendable seria trabajar con ramas)

//creamos un tag con el nombre v1.0.5

git tag -a v1.0.5 -m 'Version 1.0.5'

//podemos ver que se ha creado correctamente

git show v1.0.5

//subimos el tag al repositorio remoto

git push origin v1.0.5

//borramos el tag

git tag -d v1.0.5

Aplicación que integra Spring-Boot + AngularJS + Thymeleaf

En mi repositorio de GitHub he dejado una apicación simple que integra Spring-Boot con AngularJS utilizando lo siguiente:

– Para la configuración de Spring se ha utilizado Spring Boot junto con los siguientes módulos
. . . . 1- Spring Data JPA -> como capa de persistencia.
. . . . 2- Spring Data REST con Spring HATEOAS -> para la capa de servicios rest con los que interactuará AngularJS.
. . . . 3- Spring Security -> para la Autenticación y Autorización de la aplicación.
. . . . 4- Spring MVC con Thymeleaf -> se utiliza para gestionar principalmente los listados de consulta, así como todas las vistas que no tienen formularios.
. . . . 5- AngularJS -> se utiliza para las vistas de los formularios de detalles.
. . . . 6- Bootstrap + Angular-ui + Font Awesome + Angular-Show-Errors -> para el diseño y maquetación del front end.
. . . . 7- JUnit -> pruebas unitarias.

– Se utilizan Base de datos y servidor embebidos a modo de ejemplo: H2 y Tomcat.

– Para la creación de informes se utiliza JasperReports. Se ha configurado el pom para que a partir de los ficheros /src/main/resources/static/reports/*.jrxml y genere los /src/main/webapp/jasper/*.jasper. Para ello basta con ejecutar mvn generate-resources.

– La gestión de dependencias se realiza con: Maven y bower.

Instalación
=========
1- Instalar maven (utilizada la 3.0.5)
2- Instalar el wraper de maven para spring-boot:

mvn -N io.takari:maven:wrapper

3- Se puede ejecutar de varias formas:

//Con maven:	
mvn spring-boot:run. 

//o bien

//Construyendo el jar:      
mvn clean package 
//Y haciéndolo correr con:  
java -jar target/springangularjs-0.0.1-SNAPSHOT.jar

4- Si todo va bien la aplicación correrá en: http://localhost:8080/
5- Copiar proyecto e importarlo al eclipse como proyecto de maven.
6- Recordar que para modificar las librerías de js es necesario bower. Para ello:
. . . . a- se necesita tener instalado node.js (https://nodejs.org/)
. . . . b- se necesita también tener instalado git (https://git-scm.com/download/win)
. . . . c- instalamos bower con:

                  npm install -g bower

. . . . d- finalmente ejecutando «bower install» en el proyecto nos colocara en el directorio /src/main/resources/static/bower_components las versiones de las librerías indicadas en el bower.json.

Todo el código esta subido al GitHub
Esquema de la Arquitectura
Digrama de clases