Skip to content

DEVELOPER.md

Latest commit

 

History

History
91 lines (59 loc) · 3.11 KB

DEVELOPER.md

File metadata and controls

91 lines (59 loc) · 3.11 KB

DDEV add-on test action

Developer guide

Table of Contents

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.

First, install it:

npm install -g doctoc

Then, run it in the root folder:

doctoc README.md --maxlevel 4 && doctoc docs/* --maxlevel 4

Release process

We are using semantic versioning 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 using Actions -> Create Release -> Tag Name.

Alternatively, you could use the GitHub 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.