Skip to content

Latest commit

 

History

History
71 lines (58 loc) · 3.79 KB

DEVELOPMENT.md

File metadata and controls

71 lines (58 loc) · 3.79 KB
Raw

Development

Setup

We are using Bundler for ruby gems installation, for installing CocoaPods and fastlane. Make sure to install bundler and then run ./scripts/setup.sh that will install gems and pods. Then use bundler to run fastlane actions such as bundle exec fastlane test.

General practices

We recommend following Clean Code principles.

Coding Style

To ensure code style consistency, it must respect the following:

  1. Code Formatted and Linted:
    • Obj-C: ClangFormat. (Checked by CI)
    • Swift: swift-format. (Not checked by CI)
    • Swift: SwiftLint. (Checked by CI)
    • You can format whole repository with bundle exec fastlane format
    • Alternatively to ease your workflow, you can also add a git hook with: cp tools/code-format-git-hook.sh .git/hooks/pre-commit
  2. Follow Ray Wenderlich's coding style.

Tests

As much as possible, respect the "Arrange, Act, Assert" convention in the tests.

The tests in this project are organised according to the following conventions:

  • Unit tests are located within the UnitTests directory.
  • Integration tests are written in the IntegrationTests directory.
  • The subset of integration tests which represent one of the functional tests defined here are post-fixed with FunctionTests. The rest are post-fixed with IntegrationTests.

Release

  1. Bump version:

    • Releases: bundle exec fastlane version_bump version:x.y.z
    • For RCs use version:x.y.z-rc1
    • If you release several times the same x.y.z version, for instance several RCs, you have to bump bundle version, you can do this adding an extra build:2 argument. e.g. bundle exec fastlane version_bump version:x.y.z-rc2 build:2

  2. Ensure CHANGELOG.md is up to date and properly formatted:

    • Sections separated by lines --- are used to split the changelog
    • The first section without version line will be used as Release description

  3. Check changes and submit a PR / merge if needed

  4. Push a semver compliant version tag (x.y.z or x.y.z-rc1) to GitHub

  5. Review the added GitHub release draft, publish it

  6. Once published, it will trigger another Release to CocoaPods workflow that will push the spec to CocoaPods

  7. Profit 🚀🥳

Testing with Sdk from CocoaPods

In CriteoAdViewer, there is a workspace and Podfile, which:

  • Are intended only to test Sdk from CocoaPods
  • Are not used by top level workspace
  • Doesn't need to be actively maintained as CI does not use them

Usage

  • Edit CriteoAdViewer/Podfile if needed
  • Run pod install from this CriteoAdViewer folder, keep an eye on the version installed in logs
  • From Xcode delete CriteoPublisherSdk.framework from Frameworks

Note: When running pod install in this folder, CocoaPods will alter the project, please do not merge your changes as it could interfere with the main workspace.