From f3be443f518ee282d2735d309cbde9e417a22d59 Mon Sep 17 00:00:00 2001 From: Davidson Bruno Date: Sat, 4 May 2024 10:30:29 -0300 Subject: [PATCH 1/2] docs: updated docs --- README.md | 227 ++++++++++++++++++++++++++++++++------------------- README.pt.md | 225 +++++++++++++++++++++++++++++++------------------- 2 files changed, 285 insertions(+), 167 deletions(-) diff --git a/README.md b/README.md index 9405cb8..8b5471a 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Versioning Workflow +# Versioning Workflow ![GitHub Release](https://img.shields.io/github/v/release/davidsonbrsilva/versioning-workflow) ![License](https://img.shields.io/github/license/davidsonbrsilva/versioning-workflow.svg) @@ -9,30 +9,31 @@ _Versioning Workflow_ is a tool that allows automatic versioning of your code. It is based on [_conventional commits_](https://www.conventionalcommits.org/en/v1.0.0/) and branch patterns to determine versions. The generated versions follow [semantic versioning](https://semver.org/). -## Summary +## Summary -- [Versioning Workflow](#versioning-workflow) - - [Summary](#summary) - - [Installation](#installation) - - [Usage](#usage) - - [Release creation workflow](#release-creation-workflow) - - [Using a different name for the main branch](#using-a-different-name-for-the-main-branch) - - [The `upsert_major_version` job](#the-upsert_major_version-job) - - [Pre-release creation workflow](#pre-release-creation-workflow) - - [Customizing branch names to generate versions](#customizing-branch-names-to-generate-versions) - - [Using more than one branch name to generate versions](#using-more-than-one-branch-name-to-generate-versions) - - [Contact](#contact) - - [License](#license) +- [1. Installation](#1-installation) +- [2. Usage](#2-usage) + - [2.1. Release creation workflow](#21-release-creation-workflow) + - [2.1.1. Using a different name for the main branch](#211-using-a-different-name-for-the-main-branch) + - [2.1.2. The `upsert_major_version` job](#212-the-upsert_major_version-job) + - [2.2. Pre-release creation workflow](#22-pre-release-creation-workflow) + - [2.2.1. Customizing branch names to generate versions](#221-customizing-branch-names-to-generate-versions) + - [2.2.2. Using more than one branch name to generate versions](#222-using-more-than-one-branch-name-to-generate-versions) + - [2.3. Using the `v` prefix for versions](#23-using-the-v-prefix-for-versions) + - [2.4. Customizing the release name](#24-customizing-the-release-name) + - [2.5. Adding a prefix to the release name](#25-adding-a-prefix-to-the-release-name) +- [3. Contact](#3-contact) +- [4. License](#4-license) -## Installation +## 1. Installation Copy the `create-pre-release.yml` and `create-release.yml` files from the `.github/workflows` directory to a directory with the same name at the root of your project. That's it! -## Usage +## 2. Usage There are two workflows available for you to use: the **release creation** and the **pre-release creation**. You can choose to use only the release creation workflow or combine it with the pre-release creation workflow. -### Release creation workflow +### 2.1. Release creation workflow ```yml name: Release @@ -56,60 +57,45 @@ This is the most basic way to use this workflow. It will be triggered whenever c 3. Commits that start with `fix:` generate new patch versions of the code (for example, from `0.1.0` to `0.1.1`). 4. Commits in any other pattern generate minor versions of the code (for example, from `0.1.0` to `0.2.0`). -#### Using a different name for the main branch +#### 2.1.1. Using a different name for the main branch By default, `main` is considered the main branch, but you can modify this through the `main_branch` parameter: ```yml -name: Release - -on: - push: - branches: ["master"] - -jobs: - create_release: - name: Create release - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 - permissions: - contents: write - with: - main_branch: "master" +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + main_branch: "master" ``` -#### The `upsert_major_version` job +#### 2.1.2. The `upsert_major_version` job In the `create-release.yml` file template, you will notice that there is a job called `upsert_major_version`: ```yml upsert_major_version: # Optional - name: Upsert major version - needs: create_release - permissions: - contents: write - uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1 - with: - version: ${{ needs.create_release.outputs.version }} + name: Upsert major version + needs: create_release + permissions: + contents: write + uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1 + with: + version: ${{ needs.create_release.outputs.version }} ``` This job is optional and can be removed if you want. With each release version, it generates a `v[major_version]` tag (for example, `v1`) and keeps it updated, always referencing the latest version, until a new major version is released. -### Pre-release creation workflow +### 2.2. Pre-release creation workflow ```yml -name: Pre-release - -on: - pull_request: - branches: ["main"] - types: ["opened", "synchronize", "reopened"] - -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - permissions: - contents: write +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write ``` This is the most basic way to use the pre-release workflow. It will be triggered on pull request events: on opening, during new commits, and on reopening. Each new change in a pull request will generate a release candidate version (`-rc-`). @@ -124,7 +110,7 @@ Release candidate versions are incremented with each new change (for example, fr > If the branch does not match any of the previous patterns, the automatic pre-release version will not be generated. -#### Customizing branch names to generate versions +#### 2.2.1. Customizing branch names to generate versions Just like in the release creation workflow, you can also inform a different name for the main branch through `main_branch`. The same goes for feature, release, and hotfix branches: @@ -132,45 +118,118 @@ Just like in the release creation workflow, you can also inform a different name 2. To generate patch versions, the workflow will look for branches that match the pattern of the `hotfix_branches` parameter. If the parameter is not informed, the value `hotfix` will be considered as the default name. ```yml -name: Pre-release - -on: - pull_request: - branches: ["main"] - types: ["opened", "synchronize", "reopened"] - -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - permissions: - contents: write - with: - main_branch: "main" - feature_branches: "feature" - release_branches: "release" - hotfix_branches: "hotfix" +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + main_branch: "main" + feature_branches: "feature" + release_branches: "release" + hotfix_branches: "hotfix" ``` -#### Using more than one branch name to generate versions +#### 2.2.2. Using more than one branch name to generate versions Finally, you can also use more than one branch name for the `feature_branches`, `release_branches`, and `hotfix_branches` parameters, if you want. For example: ```yml -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - with: - feature_branches: "feat feature" # will accept source branch match for both 'feat' and 'feature' - release_branches: "rel release" # will accept source branch match for both 'rel' and 'release' - hotfix_branches: "fix hotfix" # will accept source branch match for both 'fix' and 'hotfix' +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + with: + feature_branches: "feat feature" # will accept source branch match for both 'feat' and 'feature' + release_branches: "rel release" # will accept source branch match for both 'rel' and 'release' + hotfix_branches: "fix hotfix" # will accept source branch match for both 'fix' and 'hotfix' +``` + +### 2.3. Using the `v` prefix for versions + +Some tools, like Github, suggest using versions that start with `v`, such as `v1.0.0`. You can enable this behavior using the `use_v_prefix` flag: + +**Release creation workflow** +```yaml +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + use_v_prefix: true +``` + +**Pre-release creation workflow** +```yaml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + use_v_prefix: true +``` + +### 2.4. Customizing the release name + +By default, generated release names receive the name used to generate the version. You can override this behavior using the `release_name` property: + +**Release creation workflow** +```yaml +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + release_name: "My Amazing Release" +``` + +**Pre-release creation workflow** +```yaml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + release_name: "My Amazing Release" +``` + +With this property, all created releases will receive the name "My Amazing Release" instead of the version name. + +### 2.5. Adding a prefix to the release name + +You can also define a prefix to be adopted in the release name. This is useful in cases where you still want to keep the generated version in the release name but want to add a prefix of your choice. This can be achieved through the `release_name_prefix` property: + +**Release creation workflow** +```yaml +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + release_name_prefix: "Github" ``` -## Contact +**Pre-release creation workflow** +```yaml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + release_name_prefix: "Github" +``` + +In this example, the created releases will follow the pattern "Github 1.0.0". + +## 3. Contact For questions or suggestions, send an email to . -## License +## 4. License MIT Copyright (c) 2024 Davidson Bruno diff --git a/README.pt.md b/README.pt.md index e06250b..adc8c8f 100644 --- a/README.pt.md +++ b/README.pt.md @@ -1,4 +1,4 @@ -# Versioning Workflow +# Versioning Workflow ![GitHub Release](https://img.shields.io/github/v/release/davidsonbrsilva/versioning-workflow) ![License](https://img.shields.io/github/license/davidsonbrsilva/versioning-workflow.svg) @@ -9,30 +9,31 @@ _Versioning Workflow_ é uma ferramenta que permite a geração automática de versões do seu código. Ele se baseia em [_conventional commits_](https://www.conventionalcommits.org/pt-br/v1.0.0/) e padrões de branches para determinar as versões. As versões geradas seguem o [versionamento semântico](https://semver.org/lang/pt-BR/). -## Sumário +## Índice -- [Versioning Workflow](#versioning-workflow) - - [Sumário](#sumário) - - [Instalação](#instalação) - - [Uso](#uso) - - [Workflow de criação de release](#workflow-de-criação-de-release) - - [Usando um nome diferente para a branch principal](#usando-um-nome-diferente-para-a-branch-principal) - - [O job `upsert_major_version`](#o-job-upsert_major_version) - - [Workflow de criação de pré-release](#workflow-de-criação-de-pré-release) - - [Customizando nomes de branches para gerar as versões](#customizando-nomes-de-branches-para-gerar-as-versões) - - [Usando mais de um nome de branch para gerar as versões](#usando-mais-de-um-nome-de-branch-para-gerar-as-versões) - - [Contato](#contato) - - [License](#license) +- [1. Instalação](#1-instalação) +- [2. Uso](#2-uso) + - [2.1. Workflow de criação de release](#21-workflow-de-criação-de-release) + - [2.1.1. Usando um nome diferente para a branch principal](#211-usando-um-nome-diferente-para-a-branch-principal) + - [2.1.2. O job `upsert_major_version`](#212-o-job-upsert_major_version) + - [2.2. Workflow de criação de pré-release](#22-workflow-de-criação-de-pré-release) + - [2.2.1. Customizando nomes de branches para gerar as versões](#221-customizando-nomes-de-branches-para-gerar-as-versões) + - [2.2.2. Usando mais de um nome de branch para gerar as versões](#222-usando-mais-de-um-nome-de-branch-para-gerar-as-versões) + - [2.3. Usando o prefixo `v` para as versões](#23-usando-o-prefixo-v-para-as-versões) + - [2.4. Customizando o nome da release](#24-customizando-o-nome-da-release) + - [2.5. Adicionando um prefixo ao nome da release](#25-adicionando-um-prefixo-ao-nome-da-release) +- [3. Contato](#3-contato) +- [4. License](#4-license) -## Instalação +## 1. Instalação Copie os arquivos `create-pre-release.yml` e `create-release.yml` do diretório `.github/workflows` para um diretório de mesmo nome na raiz do seu projeto. Isso é tudo! -## Uso +## 2. Uso Há dois workflows disponíveis para você usar: o de **criação de release** e o de **criação de pré-release**. Você pode optar por usar apenas o workflow de criação de release ou combiná-lo com o workflow de criação de pré-release. -### Workflow de criação de release +### 2.1. Workflow de criação de release ```yml name: Release @@ -56,60 +57,45 @@ Essa é a forma mais básica de uso desse workflow. Ele será disparado sempre q 3. _Commits_ que iniciam com `fix:` geram novas versões _patch_ do código (por exemplo, de `0.1.0` para `0.1.1`). 4. _Commits_ em qualquer outro padrão geram versões _minor_ do cóldigo (por exemplo, de `0.1.0` para `0.2.0`). -#### Usando um nome diferente para a branch principal +#### 2.1.1. Usando um nome diferente para a branch principal Por padrão, `main` é considerada como a branch principal, mas, você pode modificar isso por meio do parâmetro `main_branch`: ```yml -name: Release - -on: - push: - branches: ["master"] - -jobs: - create_release: - name: Create release - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 - permissions: - contents: write - with: - main_branch: "master" +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + main_branch: "master" ``` -#### O job `upsert_major_version` +#### 2.1.2. O job `upsert_major_version` No template do arquivo `create-release.yml`, você notará que há um job chamado `upsert_major_version`: ```yml upsert_major_version: # Optional - name: Upsert major version - needs: create_release - permissions: - contents: write - uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1 - with: - version: ${{ needs.create_release.outputs.version }} + name: Upsert major version + needs: create_release + permissions: + contents: write + uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1 + with: + version: ${{ needs.create_release.outputs.version }} ``` Esse job é opcional e pode ser removido se você quiser. A cada versão de lançamento, ele gera uma tag `v[major_version]` (por exemplo, `v1`) e a mantém atualizada, sempre referenciando a última versão, até que uma nova versão _major_ seja lançada. -### Workflow de criação de pré-release +### 2.2. Workflow de criação de pré-release ```yml -name: Pre-release - -on: - pull_request: - branches: ["main"] - types: ["opened", "synchronize", "reopened"] - -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - permissions: - contents: write +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write ``` Essa é a forma mais básica de uso do workflow de pré-release. Ele será disparado em eventos de _pull request_: na abertura, durante novos commits e na sua reabertura. Cada nova mudança em uma _pull request_ gerará uma versão _release candidate_ (`-rc-`). @@ -124,7 +110,7 @@ As versões de _release candidate_ são incrementadas a cada nova alteração (p > Se a branch não corresponder a nenhum dos padrões anteriores, a versão automática de _pré-release_ não será gerada. -#### Customizando nomes de branches para gerar as versões +#### 2.2.1. Customizando nomes de branches para gerar as versões Assim como no workflow de criação de release, você também pode informar um nome diferente para a branch principal por meio de `main_branch`. O mesmo vale para branches de feature, release e hotfix: @@ -132,45 +118,118 @@ Assim como no workflow de criação de release, você também pode informar um n 2. Para gerar versões _pacth_, o workflow procurará por branches que correspondam ao padrão do parâmetro `hotfix_branches`. Se o parâmetro não for informado, o valor `hotfix` será considerado como nome padrão. ```yml -name: Pre-release +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + main_branch: "main" + feature_branches: "feature" + release_branches: "release" + hotfix_branches: "hotfix" +``` -on: - pull_request: - branches: ["main"] - types: ["opened", "synchronize", "reopened"] +#### 2.2.2. Usando mais de um nome de branch para gerar as versões -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - permissions: - contents: write - with: - main_branch: "main" - feature_branches: "feature" - release_branches: "release" - hotfix_branches: "hotfix" +Por fim, você também pode usar mais de um nome de branch para os parâmetros `feature_branches`, `release_branches` e `hotfix_branches`, caso queira. Por exemplo: + +```yml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + with: + feature_branches: "feat feature" # aceitará correspondência da branch de origem tanto para 'feat' quanto para 'feature' + release_branches: "rel release" # aceitará correspondência da branch de origem tanto para 'rel' quanto para 'release' + hotfix_branches: "fix hotfix" # aceitará correspondência da branch de origem tanto para 'fix' quanto para 'hotfix' ``` -#### Usando mais de um nome de branch para gerar as versões +### 2.3. Usando o prefixo `v` para as versões -Por fim, você também pode usar mais de um nome de branch para os parâmetros `feature_branches`, `release_branches` e `hotfix_branches`, caso queira. Por exemplo: +Algumas ferramentas, como o Github, sugerem o uso de versões que comecem com `v` como, por exemplo, `v1.0.0`. Você pode habilitar esse comportamento através da flag `use_v_prefix`: +**Workflow de criação de release** ```yml -jobs: - create_release_candidate: - name: Create release candidate - uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 - with: - feature_branches: "feat feature" # aceitará correspondência da branch de origem tanto para 'feat' quanto para 'feature' - release_branches: "rel release" # aceitará correspondência da branch de origem tanto para 'rel' quanto para 'release' - hotfix_branches: "fix hotfix" # aceitará correspondência da branch de origem tanto para 'fix' quanto para 'hotfix' +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + use_v_prefix: true +``` + +**Workflow de criação de pre release** +```yml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + use_v_prefix: true +``` + +### 2.4. Customizando o nome da release + +Por padrão, os nomes das releases geradas recebem o nome usado para gerar a versão. Você pode sobrescrever esse comportamento através da propriedade `release_name`: + +**Workflow de criação de release** +```yml +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + release_name: "My Amazing Release" ``` -## Contato +**Workflow de criação de pre release** +```yml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + release_name: "My Amazing Release" +``` + +Com essa propriedade, todas as releases criadas receberão o nome "My Amazing Release" ao invés do nome da versão. + +### 2.5. Adicionando um prefixo ao nome da release + +Você também pode definir um prefixo a ser adotado no nome da release. Isso é útil em casos que você ainda deseja manter a versão gerada no nome da release, mas quiser adicionar um prefixo de nome de sua escolha. Isso pode ser obtido por meio da propriedade `release_name_prefix`: + +**Workflow de criação de release** +```yml +create_release: + name: Create release + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1 + permissions: + contents: write + with: + release_name_prefix: "Github" +``` + +**Workflow de criação de pre release** +```yml +create_release_candidate: + name: Create release candidate + uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1 + permissions: + contents: write + with: + release_name_prefix: "Github" +``` + +Neste exemplo, as releases criadas seguirão o padrão "Github ..", como em "Github 1.0.0". + +## 3. Contato Para dúvidas ou sugestões, envie e-mail para . -## License +## 4. License MIT Copyright (c) 2024 Davidson Bruno From 74c44471d83fed1b5dfebb9a60c24bd1bff86761 Mon Sep 17 00:00:00 2001 From: Davidson Bruno Date: Sat, 4 May 2024 11:57:09 -0300 Subject: [PATCH 2/2] fix: fixed release versioning script --- .../release-versioning/release-versioning.sh | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/actions/release-versioning/release-versioning.sh b/actions/release-versioning/release-versioning.sh index b9d7063..230d0f3 100755 --- a/actions/release-versioning/release-versioning.sh +++ b/actions/release-versioning/release-versioning.sh @@ -36,7 +36,7 @@ is_fix() { } is_minor_change() { - [[ $(is_in_branches_list "${2[@]}" "${1}") || $(is_in_branches_list "${3[@]}" "${1}") ]] + is_in_branches_list "${2}" "${1}" || is_in_branches_list "${3}" "${1}" } contains() { @@ -93,7 +93,7 @@ do_minor_change() { exit 0 } -check_pull_request_breaking_change() { +check_pull_request_for_breaking_change() { breaking_change_count=$(git log --format=%B ${1}...${2} | grep -c "^BREAKING CHANGE:.*$|^.*[^[:space:]]+!:.*$") if [[ "${breaking_change_count}" -gt 0 ]]; then major_version="${3}" @@ -120,25 +120,25 @@ check_pull_request_for_first_release() { } check_pull_request_for_minor_changes() { - local feature_branches=("${2[@]}") + local feature_branches=("${2}") - if is_missing "${2}"; then + if is_missing "${feature_branches}"; then feature_branches=("feature") printf "Feature branch names not found. Using default value: feature.\n" fi - local release_branches=("${3[@]}") + local release_branches=("${3}") - if is_missing "${3}"; then + if is_missing "${release_branches}"; then release_branches=("release") printf "Release branch names not found. Using default value: release.\n" fi if is_minor_change "${1}" "${feature_branches}" "${release_branches}"; then - local minor_version="${4}" + local minor_version="${5}" minor_version=$((minor_version + 1)) - local new_tag="${4}.${5}.0" + local new_tag="${4}.${minor_version}.0" printf "version=%s" "${new_tag}" >> "${GITHUB_OUTPUT}" printf "New generated version: %s.\n" "${new_tag}" exit 0 @@ -146,18 +146,18 @@ check_pull_request_for_minor_changes() { } check_pull_request_for_patch_changes() { - local hotfix_branches=("${2[@]}") + local hotfix_branches=("${2}") if is_missing "${2}"; then hotfix_branches=("hotfix") printf "Hotfix branch names not found. Using default value: hotfix.\n" fi - if $(is_in_branches_list "${hotfix_branches[@]}" "${1}"); then + if is_in_branches_list "${hotfix_branches}" "${1}"; then local patch_version="${5}" patch_version=$((patch_version + 1)) - local new_tag="${4}.${5}.${patch_version}" + local new_tag="${3}.${4}.${patch_version}" printf "version=%s" "${new_tag}" >> "${GITHUB_OUTPUT}" printf "New generated version: %s.\n" "${new_tag}" exit 0 @@ -165,8 +165,8 @@ check_pull_request_for_patch_changes() { } is_in_branches_list() { - local branches_list=("${1}") - local is_feature_branch=false + local branches_list_string=("${1}") + read -ra branches_list <<< "${branches_list_string}" for i in "${branches_list[@]}"; do if contains "${2}" "${i}"; then @@ -206,12 +206,12 @@ get_version() { missing_commit_sha=true fi - if [[ "${missing_commit_sha}" && $(is_missing "${COMMIT_MESSAGE}") ]]; then + if [[ "${missing_commit_sha}" == true && $(is_missing "${COMMIT_MESSAGE}") ]]; then printf "You need to inform 'HEAD_COMMIT' and 'BASE_COMMIT' or inform 'COMMIT_MESSAGE' to proceed.\n" exit 1 fi - if [[ "${missing_commit_sha}" ]]; then + if [[ "${missing_commit_sha}" == true ]]; then check_commit_for_breaking_change "${COMMIT_MESSAGE}" "${major_version}" check_commit_for_first_release "${COMMIT_MESSAGE}" "${major_version}" check_commit_for_patch_change "${COMMIT_MESSAGE}" "${major_version}" "${minor_version}" "${patch_version}"