Streamline build action

[marionbarker]

Purpose:

Bring in updates to the build actions from LoopFollow.

The streamlined build method still runs every Sunday and uses the logic that if there are updated commits or if it is the second Sunday of the month, it will trigger a build, otherwise the build is skipped.

The order of operations was modified for efficiency

• first determine if a build is warranted
• only after the build logic completes do the longer jobs get run, otherwise they are skipped
  • checks and updates certificates if necessary
  • builds the app
• the number of GitHub runners is reduced and ubuntu-latest instead of macos-15 is chosen where possible

The alive branches are no longer created or used and can be deleted from people's forks after this update is merged.

Because of the simplification from removing alive branches - the artificial requirement that the fork must have the same name as the upstream repository is removed (although it is still a good idea). In addition, any branch that exists in the upstream repository can be selected as default for the user's fork and will update when the upstream branch is updated.

There were several LoopFollow PR encompassed in this single modification for LoopCaregiver:

• LoopFollow PR 477: Revise Browser Build to Remove Alive Branches for additional design and testing information for the general GitHub actions method.
• LoopFollow PR 480: Expand and streamline build action;
• LoopFollow PR 484: fix validate_secrets regression, detect and annotate errors

Test

Push this branch to the GitHub org: docs-test, make it the default branch and do a test build using GitHub actions.

• ✅ Successful build

[marionbarker]

Summary

This modification removes the alive branch concept and enables simplification of some steps.

It adds a new step to sync the fork and to decide whether to build or not to build. If that new steps indicates a build is indicated, then the create_certs.yml is run using the same checking as before, albeit using fewer runners and ubuntu instead of macos where possible.

Rationale behind changes

The initial impetus for modifying "the architecture of the build action itself" from "like it has been" was that frequently the Wed and first-of-the-month scheduled browser build was failing because GitHub resources were impacted. The fact that "time (and cost) don’t matter because all this is for free for public repos" is irrelevant when the issue was that GitHub resources were impacted and no runners were available, so scheduled builds failed.

The first set of changes, already in Trio, was to modify the times for the scheduled build to be on Sundays.

As part of that work, I examined how to minimize the number of runners and selected ubuntu runners instead of macos runners as much as possible without redesigning the order of operations.

Removing alive branches

With the agreement of the devs for various open source apps, the next step was to remove alive branches.

A lot of complexity in the build yml file could be simplified once upkeep for alive branches was removed

• There was no longer a requirement to do two syncs (if a sync was needed), one to alive and one to either main or dev
• Instead, the sync of the current branch could be achieved with one job using an ubuntu runner
  • this adds the enhancement that any feature branch available in the upstream repo can be set as the default branch of the fork and be automatically updated at the user's discretion

Additional streamlining

With the alive branch complexity removed, I examined the steps inside the build again and moved things around. One thing I considered was that some Sundays will also be a first-of-the-month event.

I rearranged some steps, but then found that there were cases where a failure would not provide a nice error message so I added a simple check for just the GH_PAT in the first job in the build yml file.

Old Design

The graphic below shows an example of a failed scheduled run with the old design (2025-07-30). This event was a first-of-the-month build.

The different steps inside the old version of the build_trio.yml design are annotated in the graphic.

• The first step for the build yml code is to call create_certs.yml
  • The create_certs.yml code in turn calls validate_secrets.yml, which at the time used 3 jobs with 3 macos runners
  • Following successful completion of validate secrets, the create certs code checks the state of the certificate and, if necessary will nuke and create new certs when the Distribution Certs expire once a year
  • For this example, it was the attempt to get a macos runner (the 4th one requested for this scheduled build action) that failed
• Following the successful completion of create certs, there are 3 more jobs in this version of the build code

New Design

• The first step for the new build yml code is a new job that requires one ubuntu runner
  • This performs the steps to update the fork if the upstream repository has new commits
    • The Access part of validate_secrets was copied here to provide proper error reporting if the GH_PAT is not correct
    • The other parts of validate_secrets are not required and would need macos runners to perform
  • If new commits are detected, or if it is the 2nd Sunday of the month, the logic continues
    • Otherwise, the jobs for Check Certificates and Build are skipped
• Next step is to call create_certs.yml
  • The create_certs.yml code in turn calls validate_secrets.yml, which still has 3 jobs but now uses ubuntu then 2 macos runners
  • Following successful completion of validate secrets, the create certs code checks the state of the certificate and, if necessary will nuke and create new certs when the Distribution Certs expire once a year
• Following the successful completion of create certs, only one runner is required (macos) to checkout, customize, build and upload to TestFlight

The graphic below shows the build logic from Sept 2025 on the left and the logic contained in this PR on the right.

• The pink rectangles and arrow indicates that two jobs from the original build were moved forward in the process after being simplified and added to the second-Sunday-of-the-month logic.

Runner Details

Looking at the graphic above, the old design showed a job name of Access then Match-Secrets before the Fastlane job name. The new design shows only an Access job name. Each of these job names is associated with the request for a runner:

• The same code is included in the validate_secrets.yml file for the new design as for the old design but uses fewer runners
• In the new design a single runner associated with the Access job name in validate_secrets.yml sequentially runs Validate Access Token and then Validate Match-Secrets as shown in the detailed screenshot below

Options

For clarity:

• We could rename the first job name in validate_secrets to something more inclusive, such as Token and Match Secrets
• We could also rename the Access name inside the build yaml Check status to decide whether to build from Access to Validate Access Token

[dnzxy]

I still don't really agree with moving certain parts of what used to be in validate secrets into the build action, but I seem to be the only one bothered by this.

As for the rest I think the changes are sound.

@tmhastings / @MikePlante1 do the changes to testflight.md here need to be brought over to TrioDocs when/before this makes it into dev?