Skip to content

Latest commit

 

History

History
106 lines (79 loc) · 4.54 KB

CONTRIBUTING.adoc

File metadata and controls

106 lines (79 loc) · 4.54 KB

Contributing

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:

Questions

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.

Bugs

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.

New features

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:

  1. Fork the repo and create your branch from master.

  2. If you added code, add tests.

  3. Don’t forget about backward compatibility and Javadoc for public methods.

  4. Apply out Twitter based coding style .editorconfig (Idea) and Clean Code rules.

  5. Use our commit message format: Issue #699: Fixed/Added bla bla

  6. Send that Pull Request and participate in a code review.

  7. After a merge update the documentation especially if you’ve changed API (public methods).

Tests

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.
Example test structure and conventions
@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();
}

Licence

By contributing, you agree that your contributions will be licensed under its Apache License, Version 2.0.

References

This document was adapted from the open-source contribution guidelines: Facebook’s Draft, Angular.