Add support for multiple bundle IDs

[achkars]

This change helps create multiple versions of Loop for distribution.

Steps:

Create a new fork
Create a new repository variable called: TEAMID_SUFFIX
Build normally using GH actions

Impact:
If TEAMID_SUFFIX variable does NOT exists in the repository, no change to the building steps.
If TEAMID_SUFFIX variable exists, and is formatted correctly (A-Z, 0-9, 1 to 5 characters long), the new TEAMID will have a format of: TEAMID-SUFFIX (ex. Z7P62XVNWC-ABC12)

Changes:
Add TEAMID_SUFFIX repository variable to allow multiple unique Bundle IDs
Add checks to formatting in Validate_Secrets
Pass xcargs in gym to change MAIN_APP_BUNDLE_IDENTIFIER when a suffix is used.
Append TEAMID_SUFFIX to TEAM_ID variable in fastlane and all GH actions.

[marionbarker]

Overview

Thanks for looking at this again.

I'm still wondering if this is the "best" approach in that Trio / iAPS has one method and LoopFollow a second and this is yet a third method. (What you've done may be decided to be the best method.).

I think an alternative that adds the suffix as an optional item in the code itself (similar to LoopFollow_Second, etc.) would be preferred because you could have 2 branches in the same fork supporting different bundle IDs.

The simplicity of the branch idea is then only a single fork is required to get 2 bundle IDs. I think your current method requires a separate fork (with fork environment variable) to get the different bundle ids.

As someone who actually builds two apps, I'm interested in your feedback on implementation. My thoughts above are theoretical.

This topic is on my list of things to review. And I appreciate you working with me on this.

Change Request

If we do decide to do this, I would want the user to be able to run without modifying their normal configuration. As part of that, I would only want a message reporting if the variable is present - not if it is not present.

In other works - the annotation indicated in the validate link below would not be there.

Test

The test failed so I stopped testing until this is modified to work.

Configuration

1. In my local clone of dev, I created a new branch dev_plus_pr416 and then executed git pull origin pull/416/head.
2. I then pushed dev_plus_pr416 to my docs-test github organization.
3. I confirmed the commit changes match the changes in the PR.
4. I modified the default branch to be dev_plus_pr416

Test Details

Test that all the yml files work without need for modification by the user.

• ✅ Validate Secrets: https://github.com/docs-test/LoopWorkspace/actions/runs/22546872859
• ❌ Add Identifiers
  • This failed and I repeated it: first failed link: https://github.com/docs-test/LoopWorkspace/actions/runs/22547082126
  • I restored to dev as the default branch and Add Identifiers succeeded: https://github.com/docs-test/LoopWorkspace/actions/runs/22547186227

Halted the test at this point. All the yml files need to work without modification required by the user.

[achkars]

To give some background, I will be building 2 instances of Loop. One for myself (usually DEV) and one for an extended family member (always Main).

@marionbarker My preference for having 2 independent forks vs 2 branches in the same fork is that it seems safer for 2 distinct Loop instances. I want to be able to work on/debug my fork, including repository-level changes, without risking any unforeseen effects on the 2nd Loop build.

From my understanding:

• Trio reads the TeamID/BundleID from the Config.xcconfig file. There might be an advantage for xcode builders, but I don't see the upside for GH builds. I'd be curious to discuss this with Trio users/devs.
• LoopFollow, in it's current form, uses hardcoded _Second/_Third forks to allow multiple builds. This is similar to what this PR proposes, but using repository-level variables. I will revisit my LoopFollow PR to improve it with what I've learned with Loop.

[achkars]

@marionbarker Can you try your tests again? I fixed a bug tonight.