Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Commit

Permalink
[meta] reuse part of kibana CONTRIBUTING.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@jmlrt
jmlrt committed Apr 27, 2020
1 parent 607e666 commit 8e1d549
Showing 1 changed file with 140 additions and 22 deletions.
162 changes: 140 additions & 22 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,22 +1,34 @@
# Contributing to the Elastic helm charts
# Contributing to the Elastic Helm charts
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->


- [Requirements for submiting a pull request](#requirements-for-submiting-a-pull-request)
- [CLA (Contributor License Agreement)](#cla-contributor-license-agreement)
- [Branches workflow](#branches-workflow)
- [Releases](#releases)
- [Testing](#testing)
- [Templating tests](#templating-tests)
- [Integration tests](#integration-tests)
- [Adding new features](#adding-new-features)
- [Adding new features](#adding-new-features)
- [Requirements for submiting a pull request](#requirements-for-submiting-a-pull-request)
- [CLA (Contributor License Agreement)](#cla-contributor-license-agreement)
- [How We Use Git and GitHub](#how-we-use-git-and-github)
- [Forking](#forking)
- [Branching](#branching)
- [Commits and Merging](#commits-and-merging)
- [Rebasing and fixing merge conflicts](#rebasing-and-fixing-merge-conflicts)
- [What Goes Into a Pull Request](#what-goes-into-a-pull-request)
- [Releases](#releases)
- [Testing](#testing)
- [Templating tests](#templating-tests)
- [Integration tests](#integration-tests)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- Use this to update TOC: -->
<!-- docker run --rm -it -v $(pwd):/usr/src jorgeandrada/doctoc --github -->


## Adding new features

If you aren't 100% sure that this is a feature that makes sense for everyone.
Please open an issue first to discuss with the maintainers before investing a
lot of time into it.


## Requirements for submiting a pull request

Before submitting a pull request make sure you validated the following
Expand All @@ -36,17 +48,126 @@ more details).
* Integration tests should be added/updated (see [Integration tests section][]
for more details).


## CLA (Contributor License Agreement)

If you haven't already you will need to sign the [CLA][] before your pull
request can be reviewed and merged.
Please make sure you have signed our [Contributor License Agreement][]. We are
not asking you to assign copyright to us, but to give us the right to distribute
your code without restriction. We ask this of all contributors in order to
assure our users of the origin and continuing existence of the code.
You only need to sign the CLA once.


## How We Use Git and GitHub

### Forking

## Branches workflow
We follow the [GitHub forking model][] for collaborating on Helm charts code.
This model assumes that you have a remote called `upstream` which points to the
official Kibana repo, which we'll refer to in later code snippets.

Pull request are merged on `master` branch, then they should be backported to
version branches (example `7.7` branch).
### Branching

* All work on the next major release (`8.0.0`) goes into master.
* Past major release branches are named `{majorVersion}.x`. They contain work
that will go into the next minor release. For example, if the next minor release
is `7.8.0`, work for it should go into the `7.x` branch.
* Past minor release branches are named `{majorVersion}.{minorVersion}`. They
contain work that will go into the next patch release. For example, if the next
patch release is `7.7.1`, work for it should go into the `7.7` branch.
* All work is done on feature branches and merged into one of these branches.
* Where appropriate, we'll backport changes into older release branches.

### Commits and Merging

* Feel free to make as many commits as you want, while working on a branch.
* Please use your commit messages to include helpful information on your
changes and an explanation of *why* you made the changes that you did.
* Resolve merge conflicts by rebasing the target branch over your feature
branch, and force-pushing (see below for instructions).
* When merging, we'll squash your commits into a single commit.

#### Rebasing and fixing merge conflicts

Rebasing can be tricky, and fixing merge conflicts can be even trickier because
it involves force pushing. This is all compounded by the fact that attempting to
push a rebased branch remotely will be rejected by git, and you'll be prompted
to do a `pull`, which is not at all what you should do (this will really mess up
your branch's history).

Here's how you should rebase master onto your branch, and how to fix merge
conflicts when they arise.

First, make sure master is up-to-date.

```shell
git checkout master
git fetch upstream
git rebase upstream/master
```

Then, check out your branch and rebase master on top of it, which will apply all
of the new commits on master to your branch, and then apply all of your branch's
new commits after that.

```shell
git checkout name-of-your-branch
git rebase master
```

You want to make sure there are no merge conflicts. If there are merge
conflicts, git will pause the rebase and allow you to fix the conflicts before
continuing.

You can use `git status` to see which files contain conflicts. They'll be the
ones that aren't staged for commit. Open those files, and look for where git has
marked the conflicts. Resolve the conflicts so that the changes you want to make
to the code have been incorporated in a way that doesn't destroy work that's
been done in master. Refer to master's commit history on GitHub if you need to
gain a better understanding of how code is conflicting and how best to resolve
it.

Once you've resolved all of the merge conflicts, use `git add -A` to stage them
to be committed, and then use `git rebase --continue` to tell git to continue
the rebase.

When the rebase has completed, you will need to force push your branch because
the history is now completely different than what's on the remote. **This is
potentially dangerous** because it will completely overwrite what you have on
the remote, so you need to be sure that you haven't lost any work when resolving
merge conflicts. (If there weren't any merge conflicts, then you can force push
without having to worry about this.)

```
git push origin name-of-your-branch --force
```

This will overwrite the remote branch with what you have locally. You're done!

**Note that you should not run `git pull`**, for example in response to a push
rejection like this:

```
! [rejected] name-of-your-branch -> name-of-your-branch (non-fast-forward)
error: failed to push some refs to 'https://github.com/YourGitHubHandle/kibana.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

Assuming you've successfully rebased and you're happy with the code, you should
force push instead.

### What Goes Into a Pull Request

* Please include an explanation of your changes in your PR description.
* Links to relevant issues, external resources, or related PRs are very
important and useful.
* Please update any tests that pertain to your code, and add new tests where
appropriate.
* See [Submitting a Pull Request](#submitting-a-pull-request) for more info.

>TODO: add more details about version branching.

## Releases

Expand All @@ -58,7 +179,8 @@ Charts are released from version branchs (example `7.7` branch).

[Elastic Helm repository][] is updated only during releases.

>TODO: add more details about releases (see also [release.md][]).
The current release process is documented in [release.md][].


## Testing

Expand Down Expand Up @@ -116,16 +238,12 @@ cd examples/default
make goss
```

## Adding new features

If you aren't 100% sure that this is a feature that makes sense for everyone.
Please open an issue first to discuss with the maintainers before investing a
lot of time into it.

[black]: https://black.readthedocs.io/en/stable/
[cla]: https://www.elastic.co/contributor-agreement
[cla section]: #cla-contributor-license-agreement
[contributor license agreement]: https://www.elastic.co/contributor-agreement
[elastic helm repository]: https://helm.elastic.co
[github forking model]: https://help.github.com/articles/fork-a-repo/
[goss]: https://github.com/aelsabbahy/goss/blob/master/docs/manual.md
[integration test example]: https://github.com/elastic/helm-charts/blob/master/elasticsearch/examples/default/test/goss.yaml
[integration tests section]: #integration-tests
Expand Down

0 comments on commit 8e1d549

Please sign in to comment.