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.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。