我在xcode cloud授权github的时候, 提示: Xcode Cloud 与你的源代码控制提供商之间的连接未完成。但是github里查看app是安装好了

Description: I'm trying to set up Xcode Cloud for a tvOS project that uses Tuist for project generation. The workflow is created successfully, but when I try to manually start a build, no branches are listed — it just shows "There are no branches available." Setup: tvOS app project using Tuist 4.x for project generation Hosted on GitHub (private repository, organization) The .xcodeproj and .xcworkspace files were originally in .gitignore (standard practice for Tuist projects) ci_scripts/ci_post_clone.sh is configured to install Tuist and run tuist generate --no-open after cloning What I've tried: Removed *.xcodeproj and *.xcworkspace from .gitignore and committed the generated project.pbxproj to Git — branches still not visible Changed the "Project or Workspace" path in the workflow settings to match the actual location of project.pbxproj (Projects/App/.xcodeproj) — no change Temporarily changed the default branch to one that contains the committed .xcodeproj with project.pbxproj — still no branches available Verified GitHub App (Xcode Cloud) has proper repository access with read permissions for code, metadata, and pull requests Confirmed no webhook configuration issues (compared with another working repository that also has no webhooks) Key observation: When I switch the workflow's source repository to a different repository (a standard Xcode project, not Tuist-based) within the same organization, branches appear correctly. Switching back to the Tuist-based repository shows no branches again. This suggests the issue is specific to the repository structure, not GitHub permissions or workflow configuration. Project structure: Root/ ├── Workspace.swift # Tuist workspace definition ├── Tuist/ │ └── Package.swift # SPM dependencies ├── Projects/ │ └── App/ │ ├── Project.swift # Tuist project definition │ └── <project>.xcodeproj/ │ └── project.pbxproj ← (committed to Git) ├── <project>.xcodeproj/ # Root-level (no project.pbxproj, only xcshareddata/schemes) ├── ci_scripts/ │ └── ci_post_clone.sh # Installs Tuist & generates project └── .gitignore Environment: Xcode version: Latest Release (26.4) macOS: Latest Release (Tahoe 26.4) Tuist version: 4.161.0 Question How does Xcode Cloud discover branches for a repository? Does it require a valid .xcodeproj with project.pbxproj at a specific path on every branch? Is there a known limitation or recommended setup for Tuist-based projects where project files are generated at build time via ci_post_clone.sh?

Xcode Cloud seems to be queueing up builds but not processing them. Currently the earliest queued build on my end is about 3 hours ago. System status pages don't show any issues. I just want to check if this is something other people are seeing or just something going weird on our account.

Xcode Cloud builds fail at the export archive step. The critical log shows: Account "Session Proxy Provider": Unable to authenticate with App Store Connect Error Domain=DVTServicesSessionProviderCredentialITunesAuthenticationContextError Code=1 "(null)" And in DVTITunesSoftwareService.log: App Store Connect response failed with unknown failure; response (null); error (null) error: DVTServicesSessionProviderCredentialITunesAuthenticationContextError.proxy Environment: Xcode Cloud, iOS app, team type Individual (S43L28SVX2) What I have ruled out: Regenerated all DISTRIBUTION_MANAGED certificates (per thread 744683) — portal API is reachable, certs issued successfully Removed an obsolete App Groups entitlement that was causing a secondary error — that error is now gone All agreements accepted, no pending legal items Failure persists across multiple builds with identical symptoms The developer portal API responds correctly. The failure is isolated to the App Store Connect store configuration endpoint specifically, where the proxy returns response (null) — no HTTP response at all. This appears identical to thread https://developer.apple.com/forums/thread/810658 where Apple confirmed the root cause was a backend API permission issue for the team requiring an Apple-side fix. Support case 102857550486 was opened but redirected to admin support without technical investigation. Has anyone else hit this recently, or can an Apple engineer look at the backend state for this team?