feat(ARCO-281): check commit message format and PR title (#632)

Author: pawellewandowski98

.github/workflows/pr-title-check.yml

@@ -0,0 +1,19 @@
+name: Enforce Commit Message Format
+
+on:
+  pull_request:
+    types: [opened, reopened, edited, synchronize]
+
+jobs:
+  check_commit_message:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check commit message format
+        env:
+          PR_TITLE: ${{ github.event.pull_request.title }}
+        run: |
+          if [[ ! "$PR_TITLE" =~ ^(feat|chore|deps|sec|fix|refactor|docs|build|ci|test)(\([A-Z]{3,6}-[0-9]{3,6}\))?:\ .+$ ]]; then
+            echo "PR title which is used as merge commit does not follow Conventional Commits format."
+            echo "Please use format: <type>(<scope>): <description> as described in CONTRIBUTING.md"
+            exit 1
+          fi

.goreleaser.yaml

@@ -4,10 +4,6 @@
 # ---------------------------
 version: 2
 
-before:
-  hooks:
-    - make test
-    - make run_e2e_tests
 snapshot:
   version_template: "{{ .Tag }}"
 
@@ -56,18 +52,18 @@ release:
   name_template: "{{.Tag}}"
   header: |
     # 🚀 Release of {{ .ProjectName }} - {{ .Tag }}
-    
+
     **Released on**: {{ .Date }}
-    
+
     ## What's New
     Here are the latest updates, bug fixes, and features in this release:
 
   footer: |
-    ## Full Changelog: 
+    ## Full Changelog:
     You can find full changelog here: https://github.com/bitcoin-sv/arc/compare/{{ .PreviousTag }}...{{ .Tag }}
-    
+
     ## Docker Image:
     You can find docker container at [Docker Hub](https://hub.docker.com/r/bsvb/arc)
     or get it by running `docker pull bsvb/arc:{{.Version}}`
-    
+
     ### Thank you for using {{ .ProjectName }}! 🎉

.pre-commit-config.yaml

@@ -6,3 +6,10 @@ repos:
       - id: trailing-whitespace
       - id: end-of-file-fixer
       - id: check-added-large-files
+  - repo: https://github.com/dtaivpp/commit-msg-regex-hook
+    rev: v0.2.2
+    hooks:
+      - id: commit-msg-regex-hook
+        args: [ "--pattern='^(feat|chore|deps|sec|fix|refactor|docs|build|ci|test)(\\([A-Z]{3,6}-[0-9]{3,6}\\))?: .+$'",
+                "--failure_message='Commits should match the pattern: <type>(CODE-XXX)?: Message, where <type> is one of feat, sec, fix, refactor, docs, build, ci, and (CODE-XXX) is optional.'" ]
+        stages: [ commit-msg ]

CODE_OF_CONDUCT.md

@@ -3,27 +3,27 @@
 ## Introduction
 This Code of Conduct outlines the expectations for all contributors to our open-source project, as well as the responsibilities of the maintainers in ensuring a positive and productive environment. Our goal is to create excellent software. To achieve that, we foster a welcoming atmosphere for developers to collaborate and contribute to the project's success.
 
-## Expectations for Contributors  
-All contributors are expected to:  
-a. Treat others with respect and dignity.  
-b. Be considerate of differing viewpoints.  
-c. Collaborate constructively with others.  
-d. Refrain from demeaning or harassing others.  
+## Expectations for Contributors
+All contributors are expected to:
+a. Treat others with respect and dignity.
+b. Be considerate of differing viewpoints.
+c. Collaborate constructively with others.
+d. Refrain from demeaning or harassing others.
 
 ## Reporting Violations
-If you witness or experience any behavior that violates this Code of Conduct, please report it to the project maintainers. Reports can be made anonymously or by contacting a specific maintainer.  
+If you witness or experience any behavior that violates this Code of Conduct, please report it to the project maintainers. Reports can be made anonymously or by contacting a specific maintainer.
 
 ## Enforcement
-The project maintainers are responsible for enforcing this Code of Conduct. They will investigate any reported violations and take appropriate action, which may include:  
-a. Issuing a warning.  
-b. Requiring an apology or remediation.  
-c. Temporarily suspending or permanently banning a contributor from the project.  
+The project maintainers are responsible for enforcing this Code of Conduct. They will investigate any reported violations and take appropriate action, which may include:
+a. Issuing a warning.
+b. Requiring an apology or remediation.
+c. Temporarily suspending or permanently banning a contributor from the project.
 
 ## Maintainer Responsibilities
-Maintainers are responsible for:  
-a. Upholding the Code of Conduct and setting a positive example for the community.  
-b. Investigating and addressing reported violations in a fair and timely manner.  
-c. Making decisions about merging code based on its merit alone, without bias or favoritism.  
+Maintainers are responsible for:
+a. Upholding the Code of Conduct and setting a positive example for the community.
+b. Investigating and addressing reported violations in a fair and timely manner.
+c. Making decisions about merging code based on its merit alone, without bias or favoritism.
 
 ## Changes to the Code of Conduct
 This Code of Conduct is subject to change as the project evolves. Any updates will be communicated to all contributors and posted in the project repository.

CONTRIBUTING.md

@@ -16,29 +16,64 @@ Thank you for considering contributing in the BSV Blockchain ecosystem! This doc
 ## General Guidelines
 
 - **Issues First**: If you're planning to add a new feature or change existing behavior, please open an issue first. This allows us to avoid multiple people working on similar features and provides a place for discussion.
-  
+
 - **Stay Updated**: Always pull the latest changes from the main branch before creating a new branch or starting on new code.
-  
+
 - **Simplicity Over Complexity**: Your solution should be as simple as possible, given the requirements.
 
 ## Code of Conduct
 
 ### Posting Issues and Comments
 
 - **Be Respectful**: Everyone is here to help and grow. Avoid any language that might be considered rude or offensive.
-  
+
 - **Be Clear and Concise**: Always be clear about what you're suggesting or reporting. If an issue is related to a particular piece of code or a specific error message, include that in your comment.
-  
+
 - **Stay On Topic**: Keep the conversation relevant to the issue at hand. If you have a new idea or unrelated question, please open a new issue.
 
 ### Coding and PRs
 
 - **Stay Professional**: Avoid including "fun" code, comments, or irrelevant file changes in your commits and pull requests.
 
+### Commit Messages
+
+- **Use Conventional Commits**: To maintain a clean, organized, and automated commit history, we follow the Conventional Commits format.
+This format allows for clear categorization of commits, enabling automated changelogs and improved collaboration.
+
+
+Each commit message should follow this structure:
+
+```
+<type>(<scope>): <description>
+```
+
+
+Where:
+
+`<type>`: Specifies the purpose of the change. Options implemented when sorting changelog:
+```
+deps     -> dependency update
+feat     -> new feature
+chore    -> updating grunt tasks, no production code change
+test     -> changes associated with the tests
+sec      -> security update
+fix      -> bug fixes
+refactor -> refactor commits
+docs     -> documentation
+build/ci -> build process update
+```
+
+`<scope>`: **(Optional)** Task or issue identifier, Example: **ARCO-001**\
+`<description>`: A brief description of the change.
+
+Example of a commit:
+
+> `feat(ARCO-001): add new feature to the project`
+
 ## Getting Started
 
 1. **Fork the Repository**: Click on the "Fork" button at the top-right corner of this repository.
-  
+
 2. **Clone the Forked Repository**: `git clone https://github.com/YOUR_USERNAME/PROJECT.git`
 
 3. **Navigate to the Directory**: `cd PROJECT`
@@ -48,33 +83,33 @@ Thank you for considering contributing in the BSV Blockchain ecosystem! This doc
 ## Pull Request Process
 
 1. **Create a Branch**: For every new feature or bugfix, create a new branch.
-  
+
 2. **Commit Your Changes**: Make your changes and commit them. Commit messages should be clear and concise to explain what was done.
-  
+
 3. **Run Tests**: Ensure all tests pass.
-  
+
 4. **Documentation**: All code must be fully annotated with comments. Update the documentation by running `make docs` before creating a pull request.
-  
+
 5. **Push to Your Fork**: `git push origin your-new-branch`.
-  
+
 6. **Open a Pull Request**: Go to your fork on GitHub and click "New Pull Request". Fill out the PR template, explaining your changes.
-  
+
 7. **Code Review**: At least two maintainers must review and approve the PR before it's merged. Address any feedback or changes requested.
-  
+
 8. **Merge**: Once approved, the PR will be merged into the main branch.
 
 ## Coding Conventions
 
 - **Code Style**: We use `Effective Go` guideline for our coding style. Run `make lint` to ensure your code adheres to this style.
 
 - **Testing**: Always include tests for new code or changes. We aim for industry-standard levels of test coverage.
-  
+
 - **Documentation**: All exported functions, structures and modules should be documented. Use comments to describe the purpose, parameters, and return values.
 
 ## Documentation and Testing
 
 - **Documentation**: Update the documentation whenever you add or modify the code. Run `make docs` to generate the latest docs.
-  
+
 - **Testing**: Write comprehensive tests, ensuring edge cases are covered. All PRs should maintain or improve the current test coverage.
 
 ## Contact & Support

Dockerfile

@@ -42,4 +42,4 @@ USER nobody
 
 EXPOSE 9090
 
-CMD ["/service/arc"]
+CMD ["/service/arc"]

Makefile

@@ -118,6 +118,7 @@ install:
 	# arch -arm64 brew install golangci-lint
 	brew install pre-commit
 	pre-commit install
+	pre-commit install --hook-type commit-msg
 
 .PHONY: install_gen
 install_gen:

README.md

@@ -254,7 +254,7 @@ Metamorph publishes new transactions to the message queue and BlockTx subscribes
 
 ### Callbacker
 
-Callbacker is a microservice that sends callbacks to a specified URL. 
+Callbacker is a microservice that sends callbacks to a specified URL.
 
 Callbacker is designed to be horizontally scalable, with each instance operating independently. As a result, they do not communicate with each other and remain unaware of each other's existence.
 

config/test_files/config.yaml

@@ -24,4 +24,4 @@ broadcasting: # settings for connection to nodes
         p2p: 18334
     - host: localhost
       port:
-        p2p: 18335
+        p2p: 18335

doc/BIP-239.md

@@ -2,13 +2,13 @@
   BIP: 239
   Layer: Applications
   Title: Transaction Extended Format (TEF)
-  Author: 
+  Author:
       Simon Ordish (@ordishs)
       Siggi Oskarsson (@icellan)
-  Comments-Summary: No comments yet. 
-  Comments-URI: - 
-  Status: Proposal 
-  Type: Standards Track 
+  Comments-Summary: No comments yet.
+  Comments-URI: -
+  Status: Proposal
+  Type: Standards Track
   Created: 2022-11-09
 </pre>
 
@@ -64,7 +64,7 @@ The input structure is the only additional thing that is changed in the Extended
 | Previous Transaction hash | TXID of the transaction the output was created in                                           | 32 bytes                      |
 | Previous Txout-index      | Index of the output (Non negative integer)                                                  | 4 bytes                       |
 | Txin-script length        | Non negative integer VI = VarInt                                                            | 1 - 9 bytes                   |
-| Txin-script / scriptSig   | Script                                                                                      | <in-script length>-many bytes | 
+| Txin-script / scriptSig   | Script                                                                                      | <in-script length>-many bytes |
 | Sequence_no               | Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF | 4 bytes                       |
 
 In the Extended Format, we extend the input structure to include the previous locking script and satoshi outputs:
@@ -74,11 +74,11 @@ In the Extended Format, we extend the input structure to include the previous lo
 | Previous Transaction hash      | TXID of the transaction the output was created in                                           | 32 bytes                        |
 | Previous Txout-index           | Index of the output (Non negative integer)                                                  | 4 bytes                         |
 | Txin-script length             | Non negative integer VI = VarInt                                                            | 1 - 9 bytes                     |
-| Txin-script / scriptSig        | Script                                                                                      | <in-script length>-many bytes   | 
+| Txin-script / scriptSig        | Script                                                                                      | <in-script length>-many bytes   |
 | Sequence_no                    | Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF | 4 bytes                         |
 | **Previous TX satoshi output** | **Output value in satoshis of previous input**                                              | **8 bytes**                     |
 | **Previous TX script length**  | **Non negative integer VI = VarInt**                                                        | **1 - 9 bytes**                 |
-| **Previous TX locking script** | **Script**                                                                                  | **\<script length>-many bytes** | 
+| **Previous TX locking script** | **Script**                                                                                  | **\<script length>-many bytes** |
 
 ## Backward compatibility