lytics / ios-sdk

MIT License
0 stars 0 forks source link

Version File and CI Support #65

Closed mgacy closed 1 year ago

mgacy commented 1 year ago

The testing plans specified SDK version as a desired data point to track; this adds Version.swift to hold that version number. It also adds a Swift package plugin to support automation of the process of incrementing that version file.

The VersionFilePlugin is a Swift PackagePlugin to generate a Version.swift file with a specified version number and bump that version according to semver rules. It uses uses semver-tool to determine the bumped version number.

My expectation is that these would be used as part of a release workflow that might look like the following:

name: Release
on:
  workflow_dispatch:
    inputs:
      release_type:
        description: Type of release
        type: choice
        required: true
        options:
          - patch
          - minor
          - major

env:
  VERSION-FILE-PATH: 'Sources/Lytics/Version.swift'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Git Checkout main
        uses: actions/checkout@v3

      - name: Bump Version File
        id: bump
        run: |
         echo "::set-output name=version::$(swift package --allow-writing-to-package-directory version-file --bump ${{ inputs.release_type }})"

      - name: Create Pull Request
        id: cpr
        uses: peter-evans/create-pull-request@v4
        with:
          commit-message: Bump Version.swift -> ${{ steps.bump.outputs.version }}
          committer: GitHub <noreply@github.com>
          author: ${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>
          branch: release
          delete-branch: true
          title: '[CI] Bump Version (${{ steps.bump.outputs.version }})'
          body: |
            Update `Version.swift` with bumped version number
            - Auto-generated by [create-pull-request][1]

            [1]: https://github.com/peter-evans/create-pull-request
          draft: false

This would be invoked manually with an option of a patch / minor / major release and would create a PR for an incremented version number. I expect that on approval / merge, a separate workflow could then be used to tag the commit and optionally create a new release.

Screen Shot 2022-11-23 at 10 37 23 AM

mgacy commented 1 year ago

This has been updated to remove the need for a GitHub action to read and increment the version number; this is now handled entirely by the plugin. That plugin has now been moved to a separate repo.