Browser Build Issue: the current method to provide automatic sync causes errors

[marionbarker]

Describe the bug After the release of 3.4, there were a number of Browser Build failures of the Check upstream and keep alive portion of build_loop.yml.

Edited to add another issue noticed by 3.4 builders. The fix for this is captured in PR 164 in addition to all the changes needed to fix the Check Upstream job errors.

• Apple changed the location of an item in their website (this was corrected in testflight.md with PR 112, but that PR did not include the update needed in validate_secrets.yml)
• old: https://appstoreconnect.apple.com/access/api
• new: https://appstoreconnect.apple.com/access/integrations/api

Attach an Issue Report N/A.

Here's a link to a failed build: Edited to remove the link because it is no longer valid

• that loopdocs-tester/LoopWorkspace repo was deleted and the loopdocs-tester username is being used for testing of PR 164. There are many examples of this error in zulipchat and Facebook.

To Reproduce

1. Sync your fork of LoopWorkspace main to LoopKit main
2. (If there is an alive branch, delete it)
3. Build Loop
4. The error occurs
5. The work-around is to manually sync the alive branch (created by build_loop.yml)
6. Build Loop and it works

Steps 5 and 6 are a temporary work-around. They do not solve the problem.

Furthermore - those same steps (delete alive, get the failure, sync alive) must be repeated if the same user wants to build dev manually, after building main. Then repeat again to switch back to main.

Expected behavior The behavior, although unfortunate, is as coded in build_loop.yml

The next comment will have the detailed steps of how the keep-alive works now (LoopWorkspace commit e70136b).

Proposed solution

My proposed solution is that we reconfigure build_loop.yml to only provide automatic sync for the main branch. Any other branch should not attempt to automatically sync. I expect there to be some discussion on this. Once we settle on a solution, there will be a PR to patch both main and dev branches for LoopWorkspace

[marionbarker]

Here are the steps of the as-written code for automatic sync with LoopWorkspace commit e70136b.

Details

The way this currently works is this.

• Compare fork's alive branch with upstream's branch of name of branch you are trying to build
• If number of commits > 1, sync alive branch with upstream branch of same name, store a boolean variable that equates the condition # of commits > 1
• Proceed with build step
• Do a bunch of checking conditions (around what triggered the workflow, what env variables are set around automation, etc.)
• If aforementioned variable is true, do the actual syncing now, so
• Attempt to sync branch that user wants to build with upstream branch of same name
• Do some logging whether there were upstream changes
• Checkout updated codebase into build container
• Build
• Tag and artifact
• Upload to TF

We are now potentially running into issues, because we are attempting to sync alive with the upstream branch of same name, and it may have been created from a different branch and this can lead to merge conflicts for the attempted sync of alive, because the tooling we are using to sync (aormsby/Fork-Sync-With-Upstream-action@v3.4.1) will fail the pipeline (i.e. action) when it runs into merge conflicts upon attempted sync.

[marionbarker]

This was fixed (for main) with LoopWorkspace PR 164 merged on 19 July 2024 as part of Loop 3.4.1 patch.

A similar update is expected for LoopWorkspace dev, but that one is less critical because the build for the dev branch is not broken.