Home

Awesome

<!-- This source file is part of the StanfordBDHG Template Application project SPDX-FileCopyrightText: 2023 Stanford University SPDX-License-Identifier: MIT -->

Template Application

Build and Test codecov DOI

This repository contains the StanfordBDHG Template Application. It serves as a template repository for projects requiring a mobile application using continuous integration and continuous delivery setup.

Continous Delivery Workflows

Beta Deployment

The Beta Deployment workflow is triggered when a new commit is added to the main branch.

It first runs the Build and Test workflow to ensure all tests are passing. Once the Build and Test workflow passes, it builds the iOS application so it can be archived and sent to TestFlight for internal beta deployment.

Build and Test

The Build and Test workflow builds and tests the iOS application, shared Swift package, and web service. It runs all unit and user interface (UI) tests defined in the targets. The iOS application is tested on the iOS simulator on macOS. The shared and web service Swift packages are tested on Linux and macOS as well as in release and debug configuration to demonstrate all possible variations.

SwiftLint

The Swiftlint workflow is triggered by every pull request (PR) and checks if the files found in the diff contain any SwiftLint violations. You can change the SwiftLint configuration in the .swiftlint.yml file found at the root of this repository.

Continous Delivery Setup

It is a prerequisite to have access to an Apple Developer Account that allows TestFlight releases and create an app in App Store Connect that matches the bundle identifier you have defined in the App project.

App Store Connect Access

The TestFlight deployment requires access to the App Store Connect API using an API key. Please follow the Apple instructions to Creating API Keys for the App Store Connect API. The key needs the App Manager access role. Store the following information in the following GitHub secrets:

Apple Xcode Certificate and Provisioning Profile

The GitHub Action imports the Apple certificate and provisioning profile from the GitHub secrets and installs them in a local KeyChain on the GitHub runner instances. Please follow the GitHub instructions to Installing an Apple certificate on macOS runners for Xcode development.

Obtaining the Apple provisioning profile requires you to follow the following steps:

  1. Register the app identifier in the Apple Developer Account Identifiers section using the bundle identifier for your application, e.g., com.schmiedmayer.continousdelivery.
  2. Create an AppStore distribution provisioning profile in the Apple Developer Account Profiles section using the app identifier you have created in the previous step.
  3. Download the provisioning profile and convert it to a Base64 representation as detailed in Installing an Apple certificate on macOS runners for Xcode development and add it as the value for the BUILD_PROVISION_PROFILE_BASE64 secret.

After following the setup steps detailed in Installing an Apple certificate on macOS runners for Xcode development and obtaining the Apple provisioning profile as described above, you should have the following secrets configured in the repository settings:

Be sure that you update the name of the provisioning profile in the Gymfile and update the app name, bundle identifier, Xcode project name, paths, and other settings in the fastlane files when modifying the template to your needs!

Swift Package and Fastlane Update ACCESS_TOKEN

The Swift Package and Fastlane Update workflow requires an ACCESS_TOKEN secret: a GitHub Personal Access Token (PAT) allowing write access to the repository. We suggest using a bot account to create the access token. Using the PAT triggers the GitHub Actions in the create PR. The GitHub documentation provides instructions on creating a PAT. The scrop of the token can be limited to the public_repo scope for public repositories or the repo scrope for private repositories as well as the workflow scope.

Removing the token input in the GitHub action workflow results in using the default GITHUB_TOKEN and the GitHub Action bot account that does not trigger any possible merge checks in the newly created PR.

Contributors

This project is based on ContinousDelivery Example by Paul Schmiedmayer. You can find a list of contributors in the CONTRIBUTORS.md file.