build: Use prettier for markdown

Stop ignoring .md files in prettier and fix existing issues.
This commit is contained in:
Ralph Hopman
2024-12-18 17:09:22 +01:00
committed by Adam Saghy
parent 5d3271dec7
commit e3fbf8b81d
21 changed files with 269 additions and 197 deletions
+10 -10
View File
@@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
+21 -15
View File
@@ -1,6 +1,6 @@
# Commit Message Conventions
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
```
<type>(<scope>): <subject>
@@ -17,42 +17,48 @@ Any line of the commit message cannot be longer than 100 characters! This allows
The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
### Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the commit id of the commit being reverted.
### Type
Must be one of the following:
* **build**: Changes that affect the build system or external dependencies (example scopes: npm, webpack etc)
* **chore**: Other changes that don't modify src or test files
* **ci**: Changes to CI configuration files and scripts (example scopes: Travis etc)
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
* **perf**: A code change that improves performance
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons etc)
* **test**: Adding missing tests or correcting existing tests
- **build**: Changes that affect the build system or external dependencies (example scopes: npm, webpack etc)
- **chore**: Other changes that don't modify src or test files
- **ci**: Changes to CI configuration files and scripts (example scopes: Travis etc)
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons etc)
- **test**: Adding missing tests or correcting existing tests
### Scope
The scope could be anything specifying place of the commit change or empty. (example: main.scss, login etc)
### Subject
The subject contains a brief and clear description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize the first letter
* no dot (.) at the end
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end
### Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
### Footer
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
## Example Commit Message
```
feat: Summarize changes in around 50 characters or less
+63 -24
View File
@@ -1,6 +1,6 @@
# Getting Started
- View the [README](../README.md) or [watch this video](https://youtu.be/OnxxC3K2oro) to get your development environment up and running.
- View the [README](../README.md) or [watch this video](https://youtu.be/OnxxC3K2oro) to get your development environment up and running.
- Learn how to [format pull requests](#submitting-a-pull-request).
- Read how to [rebase/merge upstream branches](#configuring-remotes).
- Understand our [commit message conventions](https://github.com/openMF/web-app/blob/master/.github/COMMIT_MESSAGE.md).
@@ -16,133 +16,172 @@ When contributing to this repository, please first discuss the change you wish t
Make sure you read the [Wiki](https://github.com/openMF/web-app/wiki).
Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. If you have got any questions, please email to our [mailing list](https://sourceforge.net/projects/mifos/lists/mifos-developer). You can also join our [gitter channel](https://gitter.im/openMF/web-app) to chat about your queries in real-time.
Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. If you have got any questions, please email to our [mailing list](https://sourceforge.net/projects/mifos/lists/mifos-developer). You can also join our [gitter channel](https://gitter.im/openMF/web-app) to chat about your queries in real-time.
Each active repository has its own channel to direct questions to. Also join the [official gitter channel](https://gitter.im/openMF/mifos) of Mifos.
Remember that this is an inclusive community, committed to creating a safe, positive environment. See the whole [Code of Conduct](CODE_OF_CONDUCT.md) and please follow it in all your interactions with the project.
## Submitting or Requesting an Issue/Enhancement
### Best Practices for reporting or requesting for Issues/Enhancements:
- Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
- Follow the Issue Template while creating the issue.
- Include Screenshots if any (specially for UI related issues).
- For UI enhancements or workflows, include mockups to get a clear idea.
- Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
- Follow the Issue Template while creating the issue.
- Include Screenshots if any (specially for UI related issues).
- For UI enhancements or workflows, include mockups to get a clear idea.
### Best Practices for getting assigned to work on an Issue/Enhancement:
- If you would like to work on an issue, inform in the issue ticket by commenting on it.
- Please be sure that you are able to reproduce the issue, before working on it. If not, please ask for clarification by commenting or asking the issue creator.
**Note:** Please do not work on an issue which is already being worked on by another contributor. We don't encourage creating multiple pull requests for the same issue. Also, please allow the assigned person at least 2 days to work on the issue (The time might vary depending on the difficulty). If there is no progress after the deadline, please comment on the issue asking the contributor whether he/she is still working on it. If there is no reply, then feel free to work on the issue.
## Submitting a Pull Request
### Best Practices to send Pull Requests:
- Fork the [project](https://github.com/openMF/web-app) on GitHub
- Clone the project locally into your system.
- Fork the [project](https://github.com/openMF/web-app) on GitHub
- Clone the project locally into your system.
```
git clone https://github.com/your-username/web-app.git
```
- Make sure you are in the `master` branch.
- Make sure you are in the `master` branch.
```
git checkout master
```
- Create a new branch with a meaningful name before adding and committing your changes.
- Create a new branch with a meaningful name before adding and committing your changes.
```
git checkout -b branch-name
```
- Add the files you changed. (avoid using `git add .`)
- Add the files you changed. (avoid using `git add .`)
```
git add file-name
```
- Follow the style conventions for a [meaningful commit message](COMMIT_MESSAGE.md).
- Follow the style conventions for a [meaningful commit message](COMMIT_MESSAGE.md).
```
git commit
```
- If you forgot to add some changes, you can edit your previous commit message.
- If you forgot to add some changes, you can edit your previous commit message.
```
git commit --amend
```
- Squash multiple commits to a single commit. (example: squash last two commits done on this branch into one)
- Squash multiple commits to a single commit. (example: squash last two commits done on this branch into one)
```
git rebase --interactive HEAD~2
git rebase --interactive HEAD~2
```
- Push this branch to your remote repository on GitHub.
- Push this branch to your remote repository on GitHub.
```
git push origin branch-name
```
- If any of the squashed commits have already been pushed to your remote repository, you need to do a force push.
- If any of the squashed commits have already been pushed to your remote repository, you need to do a force push.
```
git push origin remote-branch-name --force
```
- Follow the Pull request template and submit a pull request with a motive for your change and the method you used to achieve it to be merged with the `master` branch.
- If you can, please submit the pull request with the fix or improvements including tests.
- During review, if you are requested to make changes, rebase your branch and squash the multiple commits into one. Once you push these changes the pull request will edit automatically.
- Follow the Pull request template and submit a pull request with a motive for your change and the method you used to achieve it to be merged with the `master` branch.
- If you can, please submit the pull request with the fix or improvements including tests.
- During review, if you are requested to make changes, rebase your branch and squash the multiple commits into one. Once you push these changes the pull request will edit automatically.
## Configuring remotes
When a repository is cloned, it has a default remote called `origin` that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you should add another remote called `upstream`.
1. Set the `upstream`.
```
git remote add upstream https://github.com/openMF/web-app.git
```
2. Use `git remote -v` to check the status. The output must be something like this:
```
> origin https://github.com/your-username/web-app.git (fetch)
> origin https://github.com/your-username/web-app.git (push)
> upstream https://github.com/openMF/web-app.git (fetch)
> upstream https://github.com/openMF/web-app.git (push)
```
3. To update your local copy with remote changes, run the following: (This will give you an exact copy of the current remote. You should not have any local changes on your master branch, if you do, use rebase instead.)
```
git fetch upstream
git checkout master
git merge upstream/master
```
4. Push these merged changes to the master branch on your fork. Ensure to pull in upstream changes regularly to keep your forked repository up to date.
```
git push origin master
```
5. Switch to the branch you are using for some piece of work.
```
git checkout branch-name
```
6. Rebase your branch, which means, take in all latest changes and replay your work in the branch on top of this - this produces cleaner versions/history.
```
git rebase master
```
7. Push the final changes when you're ready.
```
git push origin branch-name
```
## After your Pull Request is merged
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository.
1. Delete the remote branch on GitHub.
```
git push origin --delete branch-name
```
2. Checkout the master branch.
```
git checkout master
```
3. Delete the local branch.
```
git branch -D branch-name
```
4. Update your master branch with the latest upstream version.
```
git pull upstream master
```
## Skipping a Travis CI Build
If running a build is not required for a particular commit (in some cases like an update to README.md), add [ci skip] or [skip ci] to the git commit message. Commits that have [ci skip] or [skip ci] anywhere in the commit messages are ignored by Travis CI.
That's it! Thank you for your contribution!
+5 -3
View File
@@ -1,13 +1,14 @@
---
name: Bug Report
about: Create a report to help us improve
---
## Description
Provide a brief overview of the enhancement or issue.
## Steps to Reproduce
Please add as much detail as possible to reproduce the error/issue.
Don't assume the reader knows anything about the Mifos X Web App.
@@ -16,7 +17,8 @@ Don't assume the reader knows anything about the Mifos X Web App.
## Actual Behaviour
## Settings
- Mifos X version:
- Browser used:
- Mifos X version:
- Browser used:
## Screenshots, if any
@@ -1,7 +1,6 @@
---
name: Feature Request
about: Suggest an idea for this project
---
**Is your feature request related to a problem? Please describe.**
+10 -12
View File
@@ -1,28 +1,26 @@
---
name: User Story Template
about: Template for basic user story
---
**Goal:**
As a <USER PERSONA> I want <FEATURE> so that I can <PURPOSE of FEATURE>
i.e.
i.e.
As DevOps I want Health liveness Probe on the microservice so that the health of the service can be monitored.
**Tasks:**
i.e.
**Tasks:**
i.e.
1. Add negative use-cases to Unit tests
2. Add Integration tests
3.
1. Add negative use-cases to Unit tests
2. Add Integration tests
3.
**Acceptance Criteria:**
- [ ] [LIST ITEMS]
i.e.
- [ ] [LIST ITEMS]
i.e.
- [ ] Negative use-cases for Unit Tests in the "common streaming library"
- [ ] Integration tests in the "common streaming library"
- [ ] Negative use-cases for Unit Tests in the "common streaming library"
- [ ] Integration tests in the "common streaming library"
+3
View File
@@ -1,12 +1,15 @@
## Description
Describe the changes made and why they were made instead of how they were made. List any dependencies that are required for this change.
## Related issues and discussion
#{Issue Number}
## Screenshots, if any
## Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!
- [ ] If you have multiple commits please combine them into one commit by squashing them.