TempoSDK

TempoSDK is a library containing the code that handles the display of ad content. It talks directly with Tempo backend to request ad content specifics and controls when the web view object is displayed and removed in iOS.

• Example App
• Publish to CocoaPods
• Try the TempoSDK
• Source Control
  • Branching
  • Pull Requests
• CI/CD
  • Release Drafter
    • On Pull Request Open, Re-Opened or Synchronize
    • On Push to Master
  • Publishing

Example App

1. Run cd Example
2. Run pod install. This installs all the pod dependencies and creates a "TempoSDK.xcworkspace" file.
3. Open the file "Example/TempoSDK.xcworkspace" in XCode
4. Hit Run

Publish to CocoaPods

1. Create a new release in github with an updated version number.
2. Update the version number in "TempoSDK.podspec" file to match the above github release.
3. Run pod trunk push --allow-warnings --verbose

Try the TempoSDK

Add the following line to your Podfile:

pod 'TempoSDK'

Source Control

Branching

All changes to the repository must be done on a branch separate to main. Once work is finished on a branch it can then be merged into main by creating a pull request.

Branches are recommended to use the following format:

intent/title

e.g.
feature/new-ad-type
refactor/ad-module
fix/blank-ad-issue

The start of the commit message, in this case the word feature indicates the intention of the commit. A full list of commit intentions are listed below.

The last part of the commit message is a brief description of the changes.

Intentions

• feature: Adding new functionality to the codebase
• enhancement: Enhancing an existing feature or making it more performant
• refactor: Removing/Restructuring code to better suit architectural constraints, developer productivity or performance
• fix: Fixing a bug
• chore: Any mind-numbing, painful or otherwise distasteful changes to the codebase
• test: Updating or adding tests
• build: Updating the build process
• docs: Updating or adding documentation
• action: Any GitHub Actions related work (pipeline yaml files, pipeline testing, etc)

Pull Requests

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

About Pull Requests | GitHub

Before merging our branch into development or master, we must create a pull request in the repository.

CI/CD

This repository utilises GitHub Actions workflows for both CD (Continuous Delivery/Deployment) & version management.

The workflow files can be found in .github/workflows.

Release Drafter

The release-drafter.yml workflow is the mechanism by which a release number tag is generated for pod releases of the tempo-ios-sdk repo. This tag is then used when pushing pods to the CocoaPods Trunk.

This is all achieved by the release-drafter workflow running in the following scenarios:

On Pull Request Open, Re-Opened or Synchronize

---
title: release-drafter Workflow - Pull Request
---
flowchart
    subgraph j1 [Job: 'update-release-draft']
    direction LR
        A["`Add Label to PR
            Based on Branch Name`"] --> B["`Set Version
                                            (Skip on PR)`"]
    end
    
    subgraph j2 ["`Job: 'update-podspec'
                   (Skip on PR)`"]
    direction LR
    end
    
    j1 -...-> j2

Whenever a pull request is created, the release drafter workflow runs it's autolabeler functionality which adds labels to the pull request based on the branch name.

Version numbers and their associated branch name patterns and labels are as follows:

Version Number Increment	Branch Name	Generated Label
Major (1.X.X)	N/A	breaking
Minor (X.1.X)	"feature/..." "feature-..." "feat/..." "feat-..." "enhancement/..." "enhancement-..." "enhance/..." "enhance-..." "refactor/..." "refactor-..."	feature enhancement refactor
Patch (X.X.1)	"fix/..." "fix-..." "bugfix/..." "bugfix-..." "chore/..." "chore-..."	fix chore

On Push to Master

---
title: release-drafter Workflow - Push to Master
---
flowchart
    subgraph j1 [Job: 'update-release-draft']
    direction LR
        A["`Create or Update
            Release`"] --> B["`Set Version`"]
    end
    
    subgraph j2 [Job: 'update-podspec']
    direction LR
        C["`Checkout
            Repository Code`"] --> D["`Update version
                                       in **.podspec**
                                       & **Constants.swift**`"]
        D["`Update version
            in **.podspec**
            & **Constants.swift**`"] --> E["`Check for
                                             Changes in repo`"]
        E["`Check for
            Changes in repo`"] --> F["`If Changes detected 
                                       Stage File(s) & Commit`"]
        F["`If Changes detected
            Stage File(s) & Commit`"] --> G["`If Changes detected
                                              Push Changes to **main**`"]
        G["`If Changes detected
            Push Changes to **main**`"]
    end
    
    j1 -. "`export '_version_' env var`" ..-> j2

When a pull request is closed and pushed to master, release drafter will either create a new release or append the currently opened draft release with the following:

• A bump to the required version
• Details around the closed pull request under specific headings
• Contributor details

Publishing

---
title: cocoapods-release Workflow - Publish Release
---
flowchart
    subgraph j1 [Job]
    direction LR
        A["`Checkout
            Repository Codee`"] --> B["`Push to CocoaPods`"]
    end

Once you are satisfied with a release, publish it to then trigger the push to CocoaPods. Go to Releases -> Newest draft version -> Edit -> Publish

Once a Release has been published, the cocoapods-release workflow will deploy the new release to CocoaPods using:

pod trunk push <podspec-path> --allow-warnings --verbose