|
| 1 | +# Contributing to the ECS-based logging for Java applications |
| 2 | + |
| 3 | +The APM Agent is open source and we love to receive contributions from our community — you! |
| 4 | + |
| 5 | +There are many ways to contribute, from writing tutorials or blog posts, improving the |
| 6 | +documentation, submitting bug reports and feature requests or writing code. |
| 7 | + |
| 8 | +If you want to be rewarded for your contributions, sign up for |
| 9 | +the [Elastic Contributor Program](https://www.elastic.co/community/contributor). Each time you make |
| 10 | +a valid contribution, you’ll earn points that increase your chances of winning prizes and being |
| 11 | +recognized as a top contributor. |
| 12 | + |
| 13 | +You can get in touch with us through [Discuss](https://discuss.elastic.co/c/apm), feedback and ideas |
| 14 | +are always welcome. |
| 15 | + |
| 16 | +## Code contributions |
| 17 | + |
| 18 | +If you have a bugfix or new feature that you would like to contribute, please find or open an issue |
| 19 | +about it first. Talk about what you would like to do. It may be that somebody is already working on |
| 20 | +it, or that there are particular issues that you should know about before implementing the change. |
| 21 | + |
| 22 | +### Submitting your changes |
| 23 | + |
| 24 | +Generally, we require that you test any code you are adding or modifying. Once your changes are |
| 25 | +ready to submit for review: |
| 26 | + |
| 27 | +1. Sign the Contributor License Agreement |
| 28 | + |
| 29 | + Please make sure you have signed |
| 30 | + our [Contributor License Agreement](https://www.elastic.co/contributor-agreement/). We are not |
| 31 | + asking you to assign copyright to us, but to give us the right to distribute your code without |
| 32 | + restriction. We ask this of all contributors in order to assure our users of the origin and |
| 33 | + continuing existence of the code. You only need to sign the CLA once. |
| 34 | + |
| 35 | +2. Test your changes |
| 36 | + |
| 37 | + Run the test suite to make sure that nothing is broken. See [testing](#testing) for details. |
| 38 | + |
| 39 | +3. Rebase your changes |
| 40 | + |
| 41 | + Update your local repository with the most recent code from the main repo, and rebase your branch |
| 42 | + on top of the latest master branch. We prefer your initial changes to be squashed into a single |
| 43 | + commit. Later, if we ask you to make changes, add them as separate commits. This makes them |
| 44 | + easier to review. As a final step before merging we will either ask you to squash all commits |
| 45 | + yourself or we'll do it for you. |
| 46 | + |
| 47 | +4. Submit a pull request |
| 48 | + |
| 49 | + Push your local changes to your forked copy of the repository |
| 50 | + and [submit a pull request](https://help.github.com/articles/using-pull-requests). In the pull |
| 51 | + request, choose a title which sums up the changes that you have made, and in the body provide |
| 52 | + more details about what your changes do. Also mention the number of the issue where discussion |
| 53 | + has taken place, eg "Closes #123". |
| 54 | + |
| 55 | +5. Be patient |
| 56 | + |
| 57 | + We might not be able to review your code as fast as we would like to, but we'll do our best to |
| 58 | + dedicate it the attention it deserves. Your effort is much appreciated! |
| 59 | + |
| 60 | +### Workflow |
| 61 | + |
| 62 | +All feature development and most bug fixes hit the master branch first. Pull requests should be |
| 63 | +reviewed by someone with commit access. Once approved, the author of the pull request, or reviewer |
| 64 | +if the author does not have commit access, should "Squash and merge". |
| 65 | + |
| 66 | +### Testing |
| 67 | + |
| 68 | +You can run the following command to run all the unit tests available: |
| 69 | + |
| 70 | +```bash |
| 71 | +./mvnw test |
| 72 | +``` |
| 73 | + |
| 74 | +### Releasing |
| 75 | + |
| 76 | +The release steps have been defined in `.ci/release.sh` which it gets triggered within the BuildKite context. |
| 77 | + |
| 78 | +Releases are triggered manually using GitHub actions, and the GitHub action is the one contacting BuildKite. |
| 79 | +To run a release then |
| 80 | +* Navigate to the [GitHub job](https://github.com/elastic/ecs-logging-java/actions/workflows/release.yml) |
| 81 | +* Choose Run workflow. |
| 82 | +* Fill the form and click `Run workflow` and wait for a few minutes to complete |
| 83 | + |
| 84 | +And email/slack message will be sent with the outcome. |
| 85 | + |
| 86 | +#### Further details |
| 87 | + |
| 88 | +* There are specific vault secrets accessible only in `secret/ci/elastic-ecs-logging-java` |
0 commit comments