Add release workflow github action

[emawby]

Description

One Line Summary

Action for building the release binaries and updating the Package.swift for a release

Details

This action is intended to

1. build the binaries needed for an iOS release
2. Update the switft package
3. open a PR with the changes.

It does NOT

1. bump version numbers
2. write release notes
3. Create the Github Release after merging the pr
4. Distribute the Cocoapod

How to use this action:

1. Create a release branch with the bumped version numbers and push it.
2. Kick-off the action from the actions tab of the Github repo specifying the version number and release branch
3. Once the action has completed and created the PR write the release notes in the body of the PR and assign reviewers.

Motivation

Improve the release process

Manual testing

See the results of a test release here

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[iAmWillShepherd]

It may be worth refining this to disallow incorrect version numbers. For instance, releasing 4.0 when you meant 5. Even better would be automatically updating it by default based on the previous version.

[emawby]

It may be worth refining this to disallow incorrect version numbers. For instance, releasing 4.0 when you meant 5. Even better would be automatically updating it by default based on the previous version.

Ya I avoided handling version numbers to keep complexity down, but this action also doesn't bump the version number in the SDK code or in the cocoa pod specs. Definitely would like to have this be as one button release as possible in the future and that is something we would need to add.

I am not too worried about making mistakes with this action right now since it just makes a PR which can be fixed after the fact.

[nan-li]

This action basically does 2 build steps from the current release instructions and make a PR?

• Run cd iOS_SDK/OneSignalSDK then run ./build_all_frameworks.sh
• Run ./update_swift_package.sh and enter the new version number when prompted.
• Make a new PR

The hardest stuff to get right is still manual, but now we have to go dig for the generated XCFramework zips to attach to the GitHub release, and still need to validate we are attaching the right files, right?

[emawby]

This action basically does 2 build steps from the current release instructions and make a PR?

• Run cd iOS_SDK/OneSignalSDK then run ./build_all_frameworks.sh
• Run ./update_swift_package.sh and enter the new version number when prompted.
• Make a new PR

The hardest stuff to get right is still manual, but now we have to go dig for the generated XCFramework zips to attach to the GitHub release, and still need to validate we are attaching the right files, right?

Yep this will help ensure that developers don't need to worry about which Xcode version they are compiling with and that the checksum in the Swift package is calculated using the correct zip.

We will have a followup action that will create the Github release, push the pods, and attach the zips.