To create automatic tags we are going to use a tool called Github Tag Bump which allows us to create tags automatically with just a few instructions.
First of all we must create a workflow and to do this we must create a folder .github/workflows
in the root folder of the project and within this we must create a file, we can call it auto_tag.yml
inside this file we are going to put the following code.
name: Auto Tag
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
Auto Tag:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v3
with:
fetch-depth: '0'
- name: Bump version and push tag
uses: anothrNick/[email protected]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
WITH_V: true
DEFAULT_BUMP: minor
This code is a workflow (Workflow) for Github Actions called "Auto Tag".Its main function is to automate the process of labeling versions of a repository based on certain events, such as thrusts (pushes) to the main branch (MAIN) and extraction requests (Pull Requets) towards the main branch.Here is your breakdown:
1.Trigger event:
-
This workflow will be activated in two events:
-
When a push is made to the
main
branch. -
When a Pull required to the
main
branch.
-
2.Work settings (Job):
-
The work is called "Auto Tag".
-
It will be executed in an instance of Ubuntu with the most recent version.
-
Scripture permits for content are configured.
3.Work steps:
-
Checkout of the repository:
-
Use
checkout
action to clone the repository in the virtual machine. -
fetch-depth
is established in '0', which means that all commits will be cloned, not just the most recent.
-
-
Version and labeling increase:
-
Use the action
anothrnick/[email protected]
. -
Configure some environment variables:
-
GITHUB_TOKEN: An access token that allows action to interact with the repository in Github.
-
WITH_V: established in True, indicating that the action must include the letter 'V' before the version label.
-
DEFAULT_BUMP: Established in Minor, which means that the version number will be increased in the 'lower' part (eg, from 1.0.0 to 1.1.0).
-
-
Variable | Descripción | Valor por defecto |
---|---|---|
GITHUB_TOKEN | Requerido para permisos de etiquetado del repositorio. | |
DEFAULT_BUMP | Tipo de incremento a usar cuando no se proporciona explícitamente (none, patch, minor, major). | Menor |
DEFAULT_BRANCH | Rama predeterminada obtenida de la variable de entorno $GITHUB_BASE_REF pero puede ser sobrescrita. Se recomienda establecer esta variable si se utiliza algo distinto a master o main como rama predeterminada, de lo contrario, en combinación con la historia completa generará un error. | $GITHUB_BASE_REF |
WITH_V | Etiqueta la versión con el carácter 'v'. | |
RELEASE_BRANCHES | Lista separada por comas de ramas que generarán las etiquetas de lanzamiento. | |
CUSTOM_TAG | Establece una etiqueta personalizada. | |
SOURCE | Operar en una ruta relativa bajo $GITHUB_WORKSPACE. | |
DRY_RUN | Determina la próxima versión sin etiquetar la rama. | Falso |
GIT_API_TAGGING | Establece si se usan llamadas de API de git cli o git para operaciones de etiquetado. | Verdadero |
INITIAL_VERSION | Establece la versión inicial antes del incremento. | 0.0.0 |
TAG_CONTEXT | Establece el contexto de la etiqueta anterior. | Repo |
PRERELEASE | Define si el flujo de trabajo se ejecuta en modo de prelanzamiento. | Falso |
PRERELEASE_SUFFIX | Sufijo para las versiones de prelanzamiento. | Beta |
VERBOSE | Imprime los registros de git. | Verdadero |
MAJOR_STRING_TOKEN | Cambia la etiqueta de mensaje de commit predeterminada para cambios mayores. | |
MINOR_STRING_TOKEN | Cambia la etiqueta de mensaje de commit predeterminada para cambios menores. | |
PATCH_STRING_TOKEN | Cambia la etiqueta de mensaje de commit predeterminada para parches. | |
NONE_STRING_TOKEN | Cambia la etiqueta de mensaje de commit predeterminada para ningún cambio. | |
BRANCH_HISTORY | Establece el historial de la rama para encontrar incrementos. | Comparar |
As we can see in the following image the execution of the tool in Github Actions is shown.
In the following image we can see how all the jobs were executed correctly.
In the following image we can see all the versions that have been created using this tool.