From 52be015e9229c387708af662d438c8792bbfe0ab Mon Sep 17 00:00:00 2001 From: junjiequan Date: Wed, 31 Jul 2024 14:32:27 +0200 Subject: [PATCH 1/3] ci: add GitHub Action to enforce PR title format --- .github/pr-title-checker-config.json | 15 +++++++++++++ ...endabot.yaml => auto-merge-dependabot.yml} | 0 .../{build-release.yaml => build-release.yml} | 0 .github/workflows/pr-title-checker.yml | 22 +++++++++++++++++++ 4 files changed, 37 insertions(+) create mode 100644 .github/pr-title-checker-config.json rename .github/workflows/{auto-merge-dependabot.yaml => auto-merge-dependabot.yml} (100%) rename .github/workflows/{build-release.yaml => build-release.yml} (100%) create mode 100644 .github/workflows/pr-title-checker.yml diff --git a/.github/pr-title-checker-config.json b/.github/pr-title-checker-config.json new file mode 100644 index 000000000..893159467 --- /dev/null +++ b/.github/pr-title-checker-config.json @@ -0,0 +1,15 @@ +{ + "LABEL": { + "name": "" + }, + "CHECKS": { + "NOTE": "You can test the regex here: https://regex101.com/r/nDeps5/1", + "regexp": "(^(?build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test|BREAKING CHANGE)(?\\([\\w\\s*-]+\\))?(?!?): (?([a-z]).+[^.|\\s])$)", + "regexpFlags": "gm" + }, + "MESSAGES": { + "success": "All OK", + "failure": "PR title not following the semantic-release guidelines. Please check https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines for more information.", + "notice": "" + } +} diff --git a/.github/workflows/auto-merge-dependabot.yaml b/.github/workflows/auto-merge-dependabot.yml similarity index 100% rename from .github/workflows/auto-merge-dependabot.yaml rename to .github/workflows/auto-merge-dependabot.yml diff --git a/.github/workflows/build-release.yaml b/.github/workflows/build-release.yml similarity index 100% rename from .github/workflows/build-release.yaml rename to .github/workflows/build-release.yml diff --git a/.github/workflows/pr-title-checker.yml b/.github/workflows/pr-title-checker.yml new file mode 100644 index 000000000..07be7fd15 --- /dev/null +++ b/.github/workflows/pr-title-checker.yml @@ -0,0 +1,22 @@ +name: PR Title Checker + +on: + pull_request: + branches: + - master + types: + - opened + - edited + - synchronize + - labeled + - unlabeled + +jobs: + check-pr-title: + runs-on: ubuntu-latest + steps: + - uses: thehanimo/pr-title-checker@v1.4.1 + with: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + pass_on_octokit_error: false + configuration_path: .github/pr-title-checker-config.json #(optional. defaults to .github/pr-title-checker-config.json) From 4d7dcf2c11dc8911124d2d0c33a0e24e42e75182 Mon Sep 17 00:00:00 2001 From: junjiequan Date: Thu, 1 Aug 2024 11:03:26 +0200 Subject: [PATCH 2/3] added pull request guidelines for PR titles in README --- README.md | 49 +++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 39 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 9b9df853b..e31f0812a 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,44 @@ If you're planning to contribute to this project by adding new functionality, we Thank you for your interest in contributing to our project! +## Pull Request Guidelines + +When creating a pull request (PR) for this repository, it's important to follow the guidelines for PR titles and PR template to ensure consistency and clarity. Proper PR titles help maintain a clear and understandable project history and facilitate better release notes. + +### PR Title Format + +All PR titles must adhere to the conventional commits format. This format helps in automating the release process and generating changelogs. The format is as follows: + +``` +(): +``` + +type: The type of change being made. It must be one of the following: + +- `feat:` A new feature +- `fix:` A bug fix +- `ci:` Continuous integration-related changes. +- `docs:` Documentation only changes +- `style:` Changes that do not affect the meaning of the code (white -space, formatting, missing semi -colons, etc) +- `refactor:` A code change that neither fixes a bug nor adds a feature +- `revert`: Reverts a previous commit. +- `perf:` A code change that improves performance +- `test:` Adding missing or correcting existing tests +- `chore:` Changes to the build process or auxiliary tools and libraries such as documentation generation +- `build:` Changes that affect the build system or external dependencies. +- `BREAKING CHANGE:` A change that introduces a breaking API change. + +scope: An `optional` description of the section of the codebase affected by the changes (e.g., api, ui, docs). This is enclosed in parentheses. + +description: A brief summary of the changes made. + +### Examples + +- feat(api): add new endpoint for data retrieval +- fix(ui): correct button alignment on mobile devices +- docs: update contributing guidelines +- BREAKING CHANGE: refactor authentication middleware to use new library + ## Get started 1. `git clone https://github.com/SciCatProject/scicat-backend-next.git` @@ -246,16 +284,7 @@ The image below shows visualized workflow. The release log is automatically populated with all commit messages since the last tag, providing a detailed changelog for the release. By default semantic-release uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). -In order to generate detailed changelog for the release, the following type for the `commit message`/`PR title` should be used: - -- feat: message - A new feature -- fix: message - A bug fix -- docs: message - Documentation only changes -- style: message - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) -- refactor: message - A code change that neither fixes a bug nor adds a feature -- perf: message - A code change that improves performance -- test: message - Adding missing or correcting existing tests -- chore: message - Changes to the build process or auxiliary tools and libraries such as documentation generation +In order to generate detailed changelog for the release, please follow the pull request guidelines for PR titles. ## License From c353df4cfdf286f85a7b155fa388da9509e0533f Mon Sep 17 00:00:00 2001 From: junjiequan Date: Thu, 1 Aug 2024 13:02:21 +0200 Subject: [PATCH 3/3] add docs for pr and release guide --- README.md | 68 ------------------- .../contributing/pr-guidelines.md | 37 ++++++++++ docs/developer-guide/release-guidelines.md | 27 ++++++++ 3 files changed, 64 insertions(+), 68 deletions(-) create mode 100644 docs/developer-guide/contributing/pr-guidelines.md create mode 100644 docs/developer-guide/release-guidelines.md diff --git a/README.md b/README.md index e31f0812a..50e87e5d3 100644 --- a/README.md +++ b/README.md @@ -32,44 +32,6 @@ If you're planning to contribute to this project by adding new functionality, we Thank you for your interest in contributing to our project! -## Pull Request Guidelines - -When creating a pull request (PR) for this repository, it's important to follow the guidelines for PR titles and PR template to ensure consistency and clarity. Proper PR titles help maintain a clear and understandable project history and facilitate better release notes. - -### PR Title Format - -All PR titles must adhere to the conventional commits format. This format helps in automating the release process and generating changelogs. The format is as follows: - -``` -(): -``` - -type: The type of change being made. It must be one of the following: - -- `feat:` A new feature -- `fix:` A bug fix -- `ci:` Continuous integration-related changes. -- `docs:` Documentation only changes -- `style:` Changes that do not affect the meaning of the code (white -space, formatting, missing semi -colons, etc) -- `refactor:` A code change that neither fixes a bug nor adds a feature -- `revert`: Reverts a previous commit. -- `perf:` A code change that improves performance -- `test:` Adding missing or correcting existing tests -- `chore:` Changes to the build process or auxiliary tools and libraries such as documentation generation -- `build:` Changes that affect the build system or external dependencies. -- `BREAKING CHANGE:` A change that introduces a breaking API change. - -scope: An `optional` description of the section of the codebase affected by the changes (e.g., api, ui, docs). This is enclosed in parentheses. - -description: A brief summary of the changes made. - -### Examples - -- feat(api): add new endpoint for data retrieval -- fix(ui): correct button alignment on mobile devices -- docs: update contributing guidelines -- BREAKING CHANGE: refactor authentication middleware to use new library - ## Get started 1. `git clone https://github.com/SciCatProject/scicat-backend-next.git` @@ -256,36 +218,6 @@ Following are the post that I found useful working on the migration: - https://docs.nestjs.com/openapi/types-and-parameters - https://docs.nestjs.com/openapi/decorators -## New Release Version Bump Workflow - -### Workflow Overview - -Scicat Backend controls new releases with the `GitHub-tag-and-release` GitHub Action. This workflow is triggered by push events to the release branch. It automates the version bumping and release processes based on semantic commit messages. Full documentation of the action package can be found on [github-tag-action](https://github.com/marketplace/actions/github-tag) - -The image below shows visualized workflow. -![image](https://github.com/SciCatProject/scicat-backend-next/assets/78078898/0f3c5386-4a16-4ed1-a2ee-d71ef6f34e99) - -### Workflow Trigger Condition - -> [!Caution] -> Any push to the `release` branch initiates the workflow. - -### Versioning and Release Strategy - -**Semantic Versioning:** - -- The version is automatically bumped according to the semantic PR titles, using the [semantic-release](https://github.com/semantic-release/semantic-release) conventions: - - - `fix:` prefixed titles generate a patch release. - - `feat:` prefixed titles generate a minor release. - - `BREAKING CHANGE:` in the commit message triggers a major release. - -**Auto-generated Release Notes:** - -The release log is automatically populated with all commit messages since the last tag, providing a detailed changelog for the release. By default semantic-release uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). - -In order to generate detailed changelog for the release, please follow the pull request guidelines for PR titles. - ## License This project is licensed under the GPL License - see the [LICENSE](LICENSE) file for details diff --git a/docs/developer-guide/contributing/pr-guidelines.md b/docs/developer-guide/contributing/pr-guidelines.md new file mode 100644 index 000000000..c91f31e8d --- /dev/null +++ b/docs/developer-guide/contributing/pr-guidelines.md @@ -0,0 +1,37 @@ +# Pull Request Guidelines + +When creating a pull request (PR) for this repository, it's important to follow the guidelines for PR titles and PR template to ensure consistency and clarity. Proper PR titles help maintain a clear and understandable project history and facilitate better release notes. + +## PR Title Format + +All PR titles must adhere to the conventional commits format. This format helps in automating the release process and generating changelogs. The format is as follows: + +``` +(): +``` + +type: The type of change being made. It must be one of the following: + +- `feat:` A new feature +- `fix:` A bug fix +- `ci:` Continuous integration-related changes. +- `docs:` Documentation only changes +- `style:` Changes that do not affect the meaning of the code (white -space, formatting, missing semi -colons, etc) +- `refactor:` A code change that neither fixes a bug nor adds a feature +- `revert`: Reverts a previous commit. +- `perf:` A code change that improves performance +- `test:` Adding missing or correcting existing tests +- `chore:` Changes to the build process or auxiliary tools and libraries such as documentation generation +- `build:` Changes that affect the build system or external dependencies. +- `BREAKING CHANGE:` A change that introduces a breaking API change. + +scope: An `optional` description of the section of the codebase affected by the changes (e.g., api, ui, docs). This is enclosed in parentheses. + +description: A brief summary of the changes made. + +## Examples + +- feat(api): add new endpoint for data retrieval +- fix(ui): correct button alignment on mobile devices +- docs: update contributing guidelines +- BREAKING CHANGE: refactor authentication middleware to use new library diff --git a/docs/developer-guide/release-guidelines.md b/docs/developer-guide/release-guidelines.md new file mode 100644 index 000000000..fb07eaee0 --- /dev/null +++ b/docs/developer-guide/release-guidelines.md @@ -0,0 +1,27 @@ +# New Release Version Bump Workflow + +## Workflow Overview + +Scicat Backend controls new releases with the `GitHub-tag-and-release` GitHub Action. This workflow is triggered by push events to the release branch. It automates the version bumping and release processes based on semantic commit messages. Full documentation of the action package can be found on [github-tag-action](https://github.com/marketplace/actions/github-tag) + +The image below shows visualized workflow. +![image](https://github.com/SciCatProject/scicat-backend-next/assets/78078898/0f3c5386-4a16-4ed1-a2ee-d71ef6f34e99) + +## Workflow Trigger Condition + +> [!Caution] +> Any push to the `release` branch initiates the workflow. + +## Versioning and Release Strategy + +**Semantic Versioning:** + +- The version is automatically bumped according to the semantic PR titles, using the [semantic-release](https://github.com/semantic-release/semantic-release) conventions: + + - `fix:` prefixed titles generate a patch release. + - `feat:` prefixed titles generate a minor release. + - `BREAKING CHANGE:` in the commit message triggers a major release. + +**Auto-generated Release Notes:** + +The release log is automatically populated with all commit messages since the last tag, providing a detailed changelog for the release. By default semantic-release uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines).