Skip to content

Latest commit

 

History

History
94 lines (60 loc) · 4.91 KB

CONTRIBUTING.md

File metadata and controls

94 lines (60 loc) · 4.91 KB
Raw


Contributing

We welcome suggested improvements and bug fixes for sentry-cocoa, in the form of pull requests. To get early feedback, we recommend opening up a draft PR. Please follow our official Commit Guidelines and also prefix the title of your PR according to the Commit Guidelines. The guide below will help you get started, but if you have further questions, please feel free to reach out on Discord.

PR reviews

For feedback in PRs, we use the LOGAF scale to specify how important a comment is:

  • l: low - nitpick. You may address this comment, but you don't have to.
  • m: medium - normal comment. Worth addressing and fixing.
  • h: high - Very important. We must not merge this PR without addressing this issue.

You only need one approval from a maintainer to be able to merge. For some PRs, asking specific or multiple people for review might be adequate.

Our different types of reviews:

  1. LGTM without any comments. You can merge immediately.
  2. LGTM with low and medium comments. The reviewer trusts you to resolve these comments yourself, and you don't need to wait for another approval.
  3. Only comments. You must address all the comments and need another review until you merge.
  4. Request changes. Only use if something critical is in the PR that absolutely must be addressed. We usually use h comments for that. When someone requests changes, the same person must approve the changes to allow merging. Use this sparingly.

Setting up an Environment

Run make init to get started. This will install pre-commit, bundler and Homebrew and their managed dependencies (see Gemfile and Brewfile).

Tests

The tests depend on our test server. To run the automated tests, you first need to have the server running locally with

make run-test-server

Test guidelines:

  • We write our tests in Swift. When touching a test file written in Objective-C consider converting it to Swift and then add your tests.
  • Make use of the fixture pattern for test setup code. For examples, checkout SentryClientTest or SentryHttpTransportTests.
  • Use TestData when possible to avoid setting up data classes with test values.
  • Name the variable of the class you are testing sut, which stands for system under test.

Test can either be ran inside from Xcode or via

make test

Flaky tests

If you see a test being flaky, you should ideally fix it immediately. If that's not feasible, you can disable the test in the test scheme, add a suffix _disabled to the test, so it's clear when looking at the test that it is disabled, and create a GH issue with the issue template flaky test. Disabling the test in the scheme has the advantage that the test report will state "X tests passed, Y tests failed, Z tests skipped".

Code Formatting

Please follow the convention of removing the copyright code comments at the top of files. We only keep them inside SentryCrash, as the code is based on KSCrash.

All Objective-C, C and C++ needs to be formatted with Clang Format. The configuration can be found in .clang-format. Simply run the make task before submitting your changes for review:

make format

Linting

We use Swiftlint and Clang-Format. For Swiftlint we keep a seperate config file for the tests. To run all the linters locally execute:

make lint

Environment

Please use Sentry.xcworkspace as the entry point when opening the project in Xcode. It also contains all samples for different environments.

Public Headers

To make a header public follow these steps:

Final Notes

When contributing to the codebase, please make note of the following:

  • Non-trivial PRs will not be accepted without tests (see above).
  • Please do not bump version numbers yourself.