We appreciate your input! We want to make contributing to Resilience4j as easy and transparent as possible. As a contributor, here are the guidelines we would like you to follow:
First, visit our User Guide and search Stack Overflow. Maybe somebody asked similar question in the past.
❗
|
Before you submit new issue, please search the GitHub Issues. Maybe the discussion might inform you of solutions readily available. |
If you discover unexpected behaviour or find a bug in the source code, you can help us by submitting an issue via GitHub Issues. Use ISSUE_TEMPLATE to provide required details.
-
Use a clear and descriptive title for the issue to identify the problem.
-
Explain which behavior you expected to see instead and why.
-
Format your logs, configuration or code snippets in a proper way.
We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. Having a minimal reproducible scenario gives us a wealth of important information without going back and forth to you with additional questions. We ask you to provide a minimal reproduction as a JUnit test. It allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.
You can propose a new feature by submitting an issue.
💡
|
No ideas? See issues tagged as help wanted. |
🔥
|
Even if you would like to start with a Pull Request first, please submit an issue with a proposal for your work first, to be sure that we can use it. |
For a major feature, outline your proposal in an issue so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
ℹ️
|
We use Github Flow. |
Pull Requests are the best way to propose changes to the codebase:
-
Fork the repo and create your branch from
master
. -
If you added code, add tests.
-
Don’t forget about backward compatibility and
Javadoc
for public methods. -
Apply out Twitter based coding style .editorconfig (Idea) and Clean Code rules.
-
Use our commit message format:
Issue #699: Fixed/Added bla bla
-
Send that Pull Request and participate in a code review.
-
After a merge update the documentation especially if you’ve changed API (public methods).
We use AssertJ, BDDMockito and static imports for them. Please write test body in the Arrange-Act-Assert manner. Keep Act (When) section as small as possible.
💡
|
Instead of //Given //When //Then comments separate sections by a new line.
For complex Given setup you can extract private methods.
|
@Test
public void shouldConsumeOnErrorEvent() {
retry.getEventPublisher().onError(
event -> logger.info(event.getEventType().toString()));
Supplier<String> supplier = Retry.decorateSupplier(retry, helloWorldService::returnHelloWorld);
given(helloWorldService.returnHelloWorld()).willThrow(new HelloWorldException());
Try.ofSupplier(supplier)
// assertThat(result).isEqualTo...
then(logger).should().info("ERROR");
then(helloWorldService).should(times(3)).returnHelloWorld();
}
By contributing, you agree that your contributions will be licensed under its Apache License, Version 2.0.
This document was adapted from the open-source contribution guidelines: Facebook’s Draft, Angular.