docs(*): Add developer guide [skip ci]

.github/workflows/doc-links.yml

@@ -37,3 +37,4 @@ jobs:
           gem install awesome_bot
           cd sources
           awesome_bot README.md --skip-save-results --allow-dupe --base-url http://localhost:8080/ --white-list ddev.site
+          awesome_bot docs/*.md --skip-save-results --allow-dupe --base-url http://localhost:8080/docs/ --white-list ddev.site

README.md

@@ -10,11 +10,11 @@
 ![project is maintained](https://img.shields.io/maintenance/yes/2024.svg)
 [![tests](https://github.com/ddev/github-action-add-on-test/actions/workflows/add-ons-test.yml/badge.svg)](https://github.com/ddev/github-action-add-on-test/actions/workflows/add-ons-test.yml)
 
+**Table of Contents**
+
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 
-**Table of Contents**
-
 - [Quick start](#quick-start)
 - [Inputs](#inputs)
   - [Available keys](#available-keys)
@@ -227,4 +227,6 @@ jobs:
 
 Anyone is welcome to submit a pull request to this repository.
 
+For more details on development processes, please read the [developer guide](./docs/DEVELOPER.md).
+
 **Contributed and maintained by [julienloizelet](https://github.com/julienloizelet)**

docs/DEVELOPER.md

@@ -0,0 +1,90 @@
+# DDEV add-on test action
+
+## Developer guide
+
+**Table of Contents**
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+- [Commit message](#commit-message)
+  - [Allowed message `type` values](#allowed-message-type-values)
+  - [Squash and merge pull request](#squash-and-merge-pull-request)
+- [Update documentation table of contents](#update-documentation-table-of-contents)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+## Commit message
+
+This is not formally required, but in order to have an explicit commit history, we use some commits message convention with the following format:
+
+    <type>(<scope>): <subject>
+
+Allowed `type` are defined below.
+`scope` value intends to clarify which part of the code has been modified. It can be empty or `*` if the change is a
+global or difficult to assign to a specific part.
+`subject` describes what has been done using the imperative, present tense.
+
+Example:
+
+    feat(logger): Add a new property for logger
+
+### Allowed message `type` values
+
+- chore (automatic tasks; no production code change)
+- ci (updating continuous integration process; no production code change)
+- comment (commenting;no production code change)
+- docs (changes to the documentation)
+- feat (new feature for the user)
+- fix (bug fix for the user)
+- refactor (refactoring production code)
+- style (formatting; no production code change)
+- test (adding missing tests, refactoring tests; no production code change)
+
+### Squash and merge pull request
+
+Please note that if you merge a pull request in GitHub using the "squash and merge" option (recommended), the pull request title will be used as the commit message for the squashed commit.
+
+You should ensure that the resulting commit message is valid with respect to the above convention.
+
+## Update documentation table of contents
+
+To update the table of contents in the documentation, you can use [the `doctoc` tool](https://github.com/thlorenz/doctoc).
+
+First, install it:
+
+```bash
+npm install -g doctoc
+```
+
+Then, run it in the root folder:
+
+```bash
+doctoc README.md --maxlevel 4 && doctoc docs/* --maxlevel 4
+```
+
+## Release process
+
+We are using [semantic versioning](https://semver.org/) to determine a version number. To verify the current tag,
+you should run:
+
+```
+git describe --tags `git rev-list --tags --max-count=1`
+```
+
+Before publishing a new release, there are some manual steps to take:
+
+- Update the `CHANGELOG.md` file to the current format. The release description is based on the contents of the `CHANGELOG.md` file.
+- If the release is a major release, modify the major tag in the `README.md` file wherever necessary.
+
+Then, you have to [run the action manually from the GitHub repository](https://github.com/ddev/github-action-add-on-test/actions/workflows/release.yml)
+
+Alternatively, you could use the [GitHub CLI](https://github.com/cli/cli):
+
+- publish a release:
+
+```
+gh workflow run release.yml -f tag_name=vx.y.z
+```
+
+Note that the GitHub action will fail if the tag `tag_name` already exits.