63 lines
4.3 KiB
Plaintext
63 lines
4.3 KiB
Plaintext
== Submitting a Pull Request
|
|
|
|
We encourage all community members to contribute actively to the upstream Fineract codebase. All contributions come in the form of a pull request referencing a JIRA ticket outlining the intent of the contribution.
|
|
|
|
We request that your commit message include a FINERACT JIRA issue, recommended to be put in parentheses at the end of the first line. Start with an upper case imperative verb (not past form), and a short but concise clear description. (E.g. Add enforced HideUtilityClassConstructor checkstyle (FINERACT-821) or Fix inability to reschedule when interest accrued larger than EMI (FINERACT-1109) etc.).
|
|
|
|
If your PR is failing to pass our CI build due to a test failure, then:
|
|
|
|
** Understand if the failure is due to your PR or an unrelated unstable test.
|
|
|
|
** If you suspect it is because of a "flaky" test, and not due to a change in your PR, then please do not simply wait for an active maintainer to come and help you, but instead be a proactive contributor to the project - see next steps. Do understand that we may not review PRs that are not green - it is the contributor's (that's you!) responsability to get a proposed PR to pass the build, not primarily the maintainers.
|
|
|
|
** Search for the name of the failed test on https://issues.apache.org/jira/, e.g. for AccountingScenarioIntegrationTest you would find FINERACT-899.
|
|
|
|
** If you happen to read in such bugs that tests were just recently fixed, or ignored, then rebase your PR to pick up that change.
|
|
|
|
** If you find previous comments "proving" that the same test has arbitrarily failed in at least 3 past PRs, then please do yourself raise a small separate new PR proposing to add an @Disabled // TODO FINERACT-123 to the respective unstable test (e.g. #774) with the commit message mentioning said JIRA, as always. (Please do NOT just @Disabled any existing tests mixed in as part of your larger PR.)
|
|
|
|
** If there is no existing JIRA for the test, then first please evaluate whether the failure couldn't be a (perhaps strange) impact of the change you are proposing after all. If it's not, then please raise a new JIRA to document the suspected Flaky Test, and link it to FINERACT-850. This will allow the next person coming along hitting the same test failure to easily find it, and eventually propose to ignore the unstable test.
|
|
|
|
** Then (only) Close and Reopen your PR, which will cause a new build, to see if it passes.
|
|
Of course, we very much appreciate you then jumping onto any such bugs and helping us figure out how to fix all ignored tests!
|
|
|
|
** Pull Request Size Limit documents that we cannot accept huge "code dump" Pull Requests, with some related suggestions.
|
|
|
|
Guideline for new Feature commits involving Refactoring:
|
|
|
|
[attributes]
|
|
....
|
|
If you are submitting PR for a new Feature, and it involves refactoring, try to differentiate "new Feature code" with "Refactored" by placing them in different commits. This helps review to review your code faster.
|
|
....
|
|
|
|
|
|
We have an automated Bot which marks pull requests as "stale" after a while, and ultimately automatically closes them.
|
|
|
|
|
|
The steps below are part of our Github pull request template as a checklist while submitting. Don't treat this as mere boxes to tick off but rather ensure you're following each step so your PR doesn't get rejected and it can merged in a timely manner:
|
|
|
|
### Description
|
|
|
|
Describe the changes made and why they were made.
|
|
|
|
Ignore if these details are present on the associated [Apache Fineract JIRA ticket](https://github.com/apache/fineract/pull/1284).
|
|
|
|
|
|
### Checklist
|
|
|
|
Please make sure these boxes are checked before submitting your pull request - thanks!
|
|
|
|
- [ ] Write the commit message as described above
|
|
- [ ] Acknowledge that we will not review PRs that are not passing the build _("green")_ - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
|
|
|
|
- [ ] Create/update unit or integration tests for verifying the changes made.
|
|
|
|
- [ ] Follow coding conventions as described xref:coding-conventions.adoc[here]
|
|
|
|
- [ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
|
|
|
|
- [ ] Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)
|
|
|
|
|
|
|