release: prepare release 6.1.0

.github/workflows/build.yml

@@ -0,0 +1,42 @@
+name: Java CI
+
+on:
+  push:
+    branches:
+      - master
+      - develop
+  pull_request:
+    types: [synchronize, opened, reopened]
+
+jobs:
+  sonar-cloud-check:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Set up JDK 8
+        uses: actions/setup-java@v4
+        with:
+          java-version: '8'
+          distribution: 'temurin'
+
+      - name: Cache SonarCloud packages
+        uses: actions/cache@v3
+        with:
+          path: ~/.sonar/cache
+          key: ${{ runner.os }}-sonar
+          restore-keys: ${{ runner.os }}-sonar
+
+      - name: Install dependencies and run tests with coverage
+        run: mvn clean install verify -P no-gpg --no-transfer-progress
+
+      - name: SonarQube Scan
+        uses: SonarSource/sonarqube-scan-action@master
+        with:
+          projectBaseDir: .
+        env:
+          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

CHANGELOG.md

@@ -5,6 +5,19 @@ Todos los cambios notables a este proyecto serán documentados en este archivo.
 El formato está basado en [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 y este proyecto adhiere a [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+
+## [6.1.0] - 2025-06-25
+
+Esta versión agrega una clase para la nueva funcionalidad de la API de OneClick. Los métodos existentes no tienen cambios.
+
+### Agrega:
+
+- Se agrega la clase OneclickMallBinInfo, la cual contiene el método queryBin para la consulta de información de una tarjeta registrada en OneClick.
+
+### Actualiza:
+
+- Se actualizan las dependencias necesarias para construir el proyecto.
+
 ## [6.0.0] - 2025-05-05
 
 Esta versión no tiene cambios en el comportamiento de las funcionalidades de la API.

README.md

@@ -32,6 +32,13 @@ Ahora, si gestionas las dependencias manualmente 😱 te quedan las siguientes o
 
 (Por eso te recomendamos fuertemente que uses maven u otra herramienta que gestione las dependencias por tí)
 
+## Ejecutar Test
+
+```bash
+mvn test -P no-gpg 
+```
+
+
 ## Documentación 
 
 Puedes encontrar toda la documentación de cómo usar este SDK en el sitio https://www.transbankdevelopers.cl.
@@ -45,146 +52,78 @@ La documentación relevante para usar este SDK es:
 - Primeros pasos con [Webpay](https://www.transbankdevelopers.cl/documentacion/webpay).
 - Referencia detallada sobre [Webpay](https://www.transbankdevelopers.cl/referencia/webpay).
 
-## Información para contribuir y desarrollar este SDK
 
-Esta librería usa [Project Lombok][lombok] en su desarrollo. Si bien no es necesario podrías querer instalar el [plugin][lombok-plugins]
-para tu IDE favorito con el fin de evitar que veas errores marcados por la herramienta de desarrollo.
+## Información para contribuir a este proyecto
 
-Se recomienda usar Java 8 para compilar este SDK. En Java 9 o superior la generación de Javadocs falla debido a la introducción de módulos (y a que varias clases de JavaEE en el paquete javax.* han sido movidas a módulos separados).
+### Forma de trabajo
 
-### Standares
+- Para los mensajes de commits, nos basamos en las [Git Commit Guidelines de Angular](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits).
+- Usamos inglés para los nombres de ramas y mensajes de commit.
+- Los mensajes de commit no deben llevar punto final.
+- Los mensajes de commit deben usar un lenguaje imperativo y estar en tiempo presente, por ejemplo, usar "change" en lugar de "changed" o "changes".
+- Los nombres de las ramas deben estar en minúsculas y las palabras deben separarse con guiones (-).
+- Todas las fusiones a la rama principal se deben realizar mediante solicitudes de Pull Request(PR). ⬇️
+- Se debe emplear tokens como "WIP" en el encabezado de un commit, separados por dos puntos (:), por ejemplo, "WIP: this is a useful commit message".
+- Una rama con nuevas funcionalidades que no tenga un PR, se considera que está en desarrollo.
+- Los nombres de las ramas deben comenzar con uno de los tokens definidos. Por ejemplo: "feat/tokens-configurations".
 
-- Para los commits respetamos las siguientes normas: https://chris.beams.io/posts/git-commit/
-- Usamos ingles, para los mensajes de commit.
-- Se pueden usar tokens como WIP, en el subject de un commit, separando el token con `:`, por ejemplo:
-`WIP: This is a useful commit message`
-- Para los nombres de ramas también usamos ingles.
-- Se asume, que una rama de feature no mezclada, es un feature no terminado.
-- El nombre de las ramas va en minúsculas.
-- Las palabras se separan con `-`.
-- Las ramas comienzan con alguno de los short lead tokens definidos, por ejemplo: `feat/tokens-configuration`
-
-#### Short lead tokens
-##### Commits
-- WIP = Trabajo en progreso.
-##### Ramas
-- feat = Nuevos features
-- chore = Tareas, que no son visibles al usuario.
-- bug = Resolución de bugs.
-
-### Todas las mezclas a master se hacen mediante Pull Request.
-
-### Construir el proyecto localmente
-```bash
-mvn clean compile
-```
-### Correr los test localmente
-```bash
-mvn test
-```
+### Short lead tokens permitidos
 
-### Generar un reporte de los test ejecutados localmente
-```bash
-mvn surefire-report:report
-```
+`WIP` = En progreso.
 
-### Generar un jar local
+`feat` = Nuevos features.
 
-````bash
-mvn package
-````
+`fix` = Corrección de un bug.
 
-#### Instalar jar local
+`docs` = Cambios solo de documentación.
 
-````bash
-mvn clean install
-````
+`style` = Cambios que no afectan el significado del código. (espaciado, formateo de código, comillas faltantes, etc)
 
-Si te encuentras con un error como
+`refactor` = Un cambio en el código que no arregla un bug ni agrega una funcionalidad.
 
-````bash
-[INFO] --- maven-gpg-plugin:1.6:sign (sign-artifacts) @ transbank-sdk-java ---
-gpg: signing failed: Timeout
-````
+`perf` = Cambio que mejora el rendimiento.
 
-tienes que exportar la siguiente variable de entorno:
+`test` = Agregar test faltantes o los corrige.
 
-````bash
-export GPG_TTY=$(tty)
-````
+`chore` = Cambios en el build o herramientas auxiliares y librerías.
 
-Luego, se te pedira una frase para desbloquear la firma (puedes encontrar más informacion en 1Password)
+`revert` = Revierte un commit.
 
-### Generar una nueva versión (con deploy automático a maven)
+`release` = Para liberar una nueva versión.
 
-Para generar una nueva versión, se debe crear un PR (con un título "Prepare release X.Y.Z" con los valores que correspondan para `X`, `Y` y `Z`). Se debe seguir el estándar semver para determinar si se incrementa el valor de `X` (si hay cambios no retrocompatibles), `Y` (para mejoras retrocompatibles) o `Z` (si sólo hubo correcciones a bugs).
+### Creación de un Pull Request
 
-En ese PR deben incluirse los siguientes cambios:
+- El PR debe estar enfocado en un cambio en concreto, por ejemplo, agregar una nueva funcionalidad o solucionar un error, pero un solo PR no puede agregar una nueva funcionalidad y arreglar un error.
+- El título del los PR y mensajes de commit no debe comenzar con una letra mayúscula.
+- No se debe usar punto final en los títulos.
+- El título del PR debe comenzar con el short lead token definido para la rama, seguido de ":"" y una breve descripción del cambio.
+- La descripción del PR debe detallar los cambios que se están incorporando.
+- La descripción del PR debe incluir evidencias de que los test se ejecutan de forma correcta o incluir evidencias de que los cambios funcionan y no afectan la funcionalidad previa del proyecto.
+- Se pueden agregar capturas, gif o videos para complementar la descripción o demostrar el funcionamiento del PR.
 
-1. Modificar el archivo `CHANGELOG.md` para incluir una nueva entrada (al comienzo) para `X.Y.Z` que explique en español los cambios **de cara al usuario del SDK**.
-2. Modificar este `README.md` para que los ejemplos usen la nueva versión `X.Y.Z`
-3. Modificar el archivo `pom.xml` para que la versión snapshot sea `X.Y.{Z+1}` (de manera que los snapshots que se generen después del release sean de la siguiente versión).
+#### Flujo de trabajo
 
-Luego de obtener aprobación del pull request, debe mezclarse a master e inmediatamente generar un release en GitHub con el tag `vX.Y.Z`. En la descripción del release debes poner lo mismo que agregaste al changelog.
+1. Crea tu rama desde develop.
+2. Haz un push de los commits y publica la nueva rama.
+3. Abre un Pull Request apuntando tus cambios a develop.
+4. Espera a la revisión de los demás integrantes del equipo.
+5. Para poder mezclar los cambios se debe contar con 2 aprobaciones de los revisores y no tener alertas por parte de las herramientas de inspección.
 
-Con eso Travis CI generará automáticamente una nueva versión de la librería y la publicará en Maven Central.
+### Esquema de flujo con git
 
-### Deploy manual a maven central
+![gitflow](https://wac-cdn.atlassian.com/dam/jcr:cc0b526e-adb7-4d45-874e-9bcea9898b4a/04%20Hotfix%20branches.svg?cdnVersion=1324)
 
-El deploy de una nueva version ocurre automáticamente, en Travis CI, cuando una nueva tag de git es creada.
-Los tag de git deben respetar el standard de [SemVer](https://semver.org/). Además si el commit (o PR) a master no tiene un tag asociada, se generara una version snapshot.
-Si de todas maneras necesitas hacer el release manualmente a MavenCentral ya sea de un snapshot o una nueva version, entonces debes configurar lo siguiente en tu archivo settings de maven, comúnmente ubicado en `~/.m2/settings.xml`
+## Generar una nueva versión
 
-```xml
-<settings>
-    <servers>
-        <server>
-            <id>ossrh</id>
-            <username>your-jira-id</username>
-            <password>your-jira-pwd</password>
-        </server>
-    </servers>
-    <profiles>
-        <profile>
-            <id>ossrh</id>
-            <activation>
-                <activeByDefault>true</activeByDefault>
-            </activation>
-            <properties>
-                <gpg.executable>gpg</gpg.executable>
-                <gpg.passphrase>your-gpg-pwd</gpg.passphrase>
-            </properties>
-       </profile>
-    </profiles>
-</settings>
-```
+Para generar una nueva versión, se debe crear un PR (con un título "release: prepare release X.Y.Z" con los valores que correspondan para `X`, `Y` y `Z`). Se debe seguir el estándar [SemVer](https://semver.org/lang/es/) para determinar si se incrementa el valor de `X` (si hay cambios no retrocompatibles), `Y` (para mejoras retrocompatibles) o `Z` (si sólo hubo correcciones a bugs).
 
-- `your-jira-id`: Usuario de Jira del repositorio Nexus.
-- `your-jira-pwd`: Password del usuario Jira de Nexus.
-- `your-gpg-pwd`: Frase para la el certificado de firma gpg.
+En ese PR deben incluirse los siguientes cambios:
 
-_*Nota*: para subir codigo a MavenCentral, este debe estar firmado._ [Mas información](https://dracoblue.net/dev/uploading-snapshots-and-releases-to-maven-central-with-travis/)
+1. Modificar el archivo `CHANGELOG.md` para incluir una nueva entrada (al comienzo) para `X.Y.Z` que explique en español los cambios.
+2. Modificar el archivo `pom.xml` y modificar la versión.
 
-Si quieres probar el snapshot que se genera en MavenCentral, debes agregar el repositorio de snapshots de Sonatype, a continuación 
-esta la configuración que debes agregar a tu settings `~/.m2/settings.xml`
-```xml
-<profiles>
-  <profile>
-     <id>allow-snapshots</id>
-        <activation><activeByDefault>true</activeByDefault></activation>
-     <repositories>
-       <repository>
-         <id>snapshots-repo</id>
-         <url>https://oss.sonatype.org/content/repositories/snapshots</url>
-         <releases><enabled>false</enabled></releases>
-         <snapshots><enabled>true</enabled></snapshots>
-       </repository>
-     </repositories>
-   </profile>
-</profiles>
-```
+Luego de obtener aprobación del PR, debe mezclarse a master e inmediatamente generar un release en GitHub con el tag `vX.Y.Z`. En la descripción del release debes poner lo mismo que agregaste al changelog.
 
-<!--
-# vim: set tw=79:
--->
+Con eso Github Actions generará automáticamente una nueva versión de la librería y la publicará en Maven Central.
 
+Posterior a la liberación debes mezclar la rama release en develop, finalmente realizar un rebase de la rama develop utilizando como base la rama main.