Skip to content

Latest commit

 

History

History
86 lines (67 loc) · 4.95 KB

CONTRIBUTING.md

File metadata and controls

86 lines (67 loc) · 4.95 KB
Raw

Contributing

Pull requests

Make pull requests to the develop branch. Once all tests are passing on develop, we will merge to master and release the gem.

Tests

CI setup

gooddata-ruby has a robust CI setup in place to ensure easy contributing by both GD employees and outsiders. The CI is based on travis-ci and all of the environment specifics is versioned in .travis.yml

The pipeline is split into two parts - before-merge and after-merge.

Before-merge

This pipeline has to pass before the merge of a PR. All of the checks included are runnable without special permissions or credentials (it is possible to run them as an outside contributor). It includes a suite of unit tests, automated code review tools and mocked (thru VCR) integration and E2E tests.

After-merge

This pipeline has to pass before a release is made. It extends the before-merge suite, running it against a live GD env (staging servers) and adds more thorough specs (load specs, slow specs). Special permissions and credentials are required (member of github GD organization, valid testing credentials).

Details & Caveats

It is possible to create a local "fork" of the CI environment on travis-ci.org or travis-ci.com. The forked environment will still use the versioned .travis.yml, so all of the settings (including email reporting) will be also valid on the fork. To see a solution to this, check https://confluence.intgdc.com/display/~jakub.mahnert/gooddata-ruby+CI+notification+setup (only applies to specific GD employees)

Running tests manually

Unit tests

bundle exec rake test:unit

Integration tests

Currently only GoodData employees can run integration tests for security reasons.

GD_SPEC_PASSWORD=*** bundle exec rake test:integration

Integration tests can be run against different GoodData environments or with VCR.

VCR test setup

When adding new integration test, always set :vcr metadata.

describe 'New integration test', :vcr

The VCR record mode can be set via VCR_RECORD_MODE environment variable. Set it to all to make a new recording. Please check the recorded payloads for possible sensitive data before submitting to github.

PI test setup

If you are so lucky and have acces to PI, you can run the test agains it ... there is guide in confluence

Static analysis

We use Pronto to detect code smells using static analysis.

Running locally

bundle exec pronto run --unstaged -c upstream/develop

Editor integrations:

Documentation

Yard

We use yard to auto-generate documentation from comments. Document all new and modified public methods using yard tags. Run ./yard-server.sh to see the result.

Cookbook

Usage examples can be found here. If your change deserves an example, make a PR to this repo.

Acceptance criteria

  1. The change is as small as possible. It fixes one specific issue or implements one specific feature. Do not combine things, send separate pull requests if needed.
  2. Include proper tests and make all tests pass (unless it contains a test exposing a bug in existing code). Every new class should have corresponding unit tests, even if the class is exercised at a higher level, such as a feature test.
  3. Every bug-fix has a regression test.
  4. If you suspect a failing CI build is unrelated to your contribution, you may try and restart the failing CI job or ask a developer to fix the aforementioned failing test.
  5. Code conforms to this style guide.
  6. When writing tests, please follow these guidelines.
  7. Changes do not adversely degrade performance.
  8. Your PR contains a single commit (please use git rebase -i to squash commits)
  9. When writing commit messages, please follow these guidelines.
  10. Your changes can merge without problems (if not please rebase if you're the only one working on your feature branch, otherwise, merge master).
  11. If the pull request adds any new libraries, they should be in line with our license.
  12. Use GoodData.logger for logging instead of puts.
  13. Public methods are documented and examples are added to the cookbook when applicable.

Based on GitLab's contribution guide.