FastLane and GitHub Actions for Mac-free install, for semi-automated TestFlight distributions

[bjornoleh]

Based on FastLane and GitHub Actions from LoopKit/LoopWorkspace.

It is possible to set the GitHub actions to trigger periodically by cron, or have it trigger by releases on origin. This version only require manually syncing in GitHub, then start the GithUb Actions workflow manually.

The build takes around seven minutes, then some time for processing at TestFlight.

Instructions in /fastlane/testflight.md

The LoopKit version was introduced here: https://loop.zulipchat.com/#narrow/stream/144182-development/topic/FastLane.20.2B.20GitHub.20Actions.20.2B.20TestFlight.20.3D.20Mac-free.20Loop/near/315841670

And implemented in Loop with this PR: LoopKit/LoopWorkspace#26

LoopKit docs for Loop clouds builds based on the same method: https://loopkit.github.io/loopdocs/gh-actions/gh-overview/

[bjornoleh]

This PR should be good to go, but I may also want to some improvements that were added to Loop in https://github.com/LoopKit/LoopWorkspace/commit/319b611b3349f4e7aba8d6556623e3bb8ef4e2a4.

Please let me know if/when a new release is imminent, and I will try to add this here as well:

Validate repository secrets (https://github.com/LoopKit/LoopWorkspace/pull/36)

• Validate repository secrets

Adds support for validation of repository secrets.

• Validate $FASTLANE_KEY as unencrypted PKCS#8

• Number workflows to guide sequential exection

[bjornoleh]

Ok, done. The workflows are now numbered, for more intuitive sequential runs, and a new workflow for validation of repo secrets is added, both based on https://github.com/LoopKit/LoopWorkspace/commit/319b611b3349f4e7aba8d6556623e3bb8ef4e2a4.

A commented-out template for automated builds is also included in the Build Xdrip4iOS workflow. Must uncomment to activate this, and syncing of ones personal fork must still be done manually.

If uncommenting build on push, a new build will start immediately after syncing with origin (and any code change on the personal remote).

I have tested this, and it looks fine to me. Please remember that the workflows must be present in the default branch on GitHub for them to be accessible in the Actions tab. So either change the default branch, or merge with your default branch.

Edit: on second thought, users uncommenting lines in the workflow file on their forks might actually cause merge conflicts when syncing with origin later. So perhaps uncomment and commit to origin? Or just rely on manual execution of the workflow, if it is not desirable to have automated builds for all (failed builds will generate emails).

Edit2: tested doing a sync in the GitHub website after uncommenting in the build xdripswift workflow, and it was fine. So we can keep the template for automated builds, and direct people to how to uncomment in the browser. This will make TestFlight distributions very easy to update! And removes the risk of doing anything wrong really.

[MikePlante1]

Any update on when this might be accepted into master? It will make it much easier for people who want to use xDrip4iOS with Loop but don't have a new enough Mac to build it otherwise.

[shazvic]

Any update on when this might be accepted into master? It will make it much easier for people who want to use xDrip4iOS with Loop but don't have a new enough Mac to build it otherwise.

Agree.

[bjornoleh]

I would also like a heads up for when this might make it into develop or master, as I am working on some further improvements that may or may not be ready in time. It already works well in it’s current form in this PR though. @paulplant @JohanDegraeve

[paulplant]

Hi @bjornoleh - do you consider that the PR is finished for merging now? Or will you still add commits?

[bjornoleh]

Hi, let me review this to see if there are recent changes in the corresponding files in Loop, to be sure that the PR is aligned with how this is done in Loop. I'll let you know when I have had a look

[paulplant]

Hi @bjornoleh - are you ok for me to merge this into a clean test branch and we can work on it there to clean everything up get ready to PR back into the main repo?

[bjornoleh]

Hi @paulplant, the branch is even with dev and should be good to go.

I have also been working on something in addition that may be added now or as a separate PR later:

https://github.com/bjornoleh/xdripswift/tree/update%2Bkeepalive

[paulplant]

Should the PR be modified to pull from dev_fastlane instead of update+keepalive?

[bjornoleh]

If you want me to include the latest changes, I will just fast forward the original branch to the tip of the other branch. Those two latest commits were completed only yesterday. They add a feature to let scheduled workflows work reliably, and automatically look for and pull changes from the upstream repo.

[bjornoleh]

@paulplant , I have now completed my testing and have included the commits from update+keepalive in the dev_fastlane branch. You are free to proceed as you see fit. Let me know if something is unclear.

This is the feature of the last commits:

The workflow runs on schedule every night at 04 UTC.

A job called "check_latest_from_upstream" will be looking for a branch of the same name on JohanDegraeve/xdripswift (which will be nice for someone switching between master and develop, but needs editing if using a branches that does not exist on the upstream repo), syncs any changes, checks for repository inactivity of >50 days by the keep alive action (and inserts an empty commit if needed, to avoid deactivation of scheduled workflow after 60 days of repo inactivity).

Then the "build" job runs, depending on some conditions: if the workflow was launched manually, if scheduled on the 1st of the month, or if the scheduled nightly runs finds a new commit on JohanDegraeve/xdripswift.

Today is the 1st of the month, so it built the app. Tomorrow it will only check for updates and run the keep alive action. When not building the app, the workflow only runs for 5-20 seconds.

I made the build_xdrip.yml workflow run on schedule by default. But it will not start running on schedule on forks of JohanDegraeve/xdripswift until the workflow is manually activated. If someone wants to deactivate the workflow, no code changes are required:

---