Add ci-ios PR pipeline - #635
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
db74123 to
dc792a1
Compare
ade88b9 to
f952221
Compare
dc792a1 to
2d471a8
Compare
ci-ios PR pipeline
ci-ios PR pipelineci-ios PR pipeline
Package Size
Web file breakdown
React Native file breakdown
Android file breakdown
Measured from the PR base SHA and PR head SHA. The file breakdown shows uncompressed sizes within each package artifact, so individual files do not sum to the compressed artifact total. This comment reports package artifact sizes only; it is not a final app binary-size report. |
Install this buildOpen Tophat, select your target device, then click Install. Links open on the Mac running Tophat.
Checkout Kit E2E results
FailuresCaution These E2E checks are not yet required, so they do not block merging — but a failure may still indicate a real issue to resolve before merging.
Android — react-native-android
|
ci-ios PR pipelineci-ios PR pipeline
2d471a8 to
61287b4
Compare
f952221 to
4a0efcf
Compare
| # (changes since the merge-base, not tip-to-tip). | ||
| e2e_changed_files_file() { | ||
| local changed_files | ||
| changed_files="$(e2e_deploy_dir)/changed-files.txt" |
There was a problem hiding this comment.
Could you just use a tmp file for this with mktemp?
| [PLAN_STAGE_NAME] + @selected_job_ids.map { |id| "#{WORKFLOW_PREFIX}#{id}" } | ||
| end | ||
|
|
||
| def problem_stages |
There was a problem hiding this comment.
[P1] This fails open when BITRISEIO_FINISHED_WORKFLOWS is missing, malformed, or omits an expected stage. BitrisePipelineStages.parse then yields an empty roster, problem_stages is empty, and the required check reports success—even marking a selected job as passed. I reproduced that with a nil roster. Could we require every expected stage to be present with an explicit successful status, and add tests for invalid JSON plus entirely absent plan/job entries?
| end | ||
|
|
||
| def conclusion | ||
| problem_stages.empty? ? "success" : "failure" |
There was a problem hiding this comment.
[P2] The shared stage parser treats succeeded_with_abort as success. That may be acceptable for the existing non-blocking E2E report, but for a required iOS test gate an aborted selected workflow should not count as evidence that its tests passed. Could this reporter require the literal succeeded status, or make the success policy injectable, with coverage for the aborted status?
| e2e_branch_bitrise_config() { | ||
| local branch_config | ||
| branch_config="$(e2e_deploy_dir)/branch-bitrise.yml" | ||
| if [ -z "${BITRISE_PULL_REQUEST:-}" ] || [ -z "${BITRISE_GIT_COMMIT:-}" ] || ! git show "${BITRISE_GIT_COMMIT}:e2e/bitrise.yml" > "$branch_config" 2>/dev/null; then |
There was a problem hiding this comment.
[P2] On a PR build, silently falling back to the merged e2e/bitrise.yml when the branch-head config cannot be read defeats the drift protection this helper is meant to provide. The coverage assertion then checks the wrong graph and can pass even though the selected workflow does not exist in the graph Bitrise resolved. Could the PR path fail closed with the rebase hint, keeping this fallback only for non-PR runs?
Part of the macOS CI speed-up. Tracked on shop/issues-checkout-kit#1206, under shop/issues-checkout-kit#1202. ## Why a new pipeline Bitrise reports one status per pipeline. Reusing the `e2e` pipeline would tie the merge gate to the BrowserStack device flake that `e2e/BITRISE.md:53` deliberately keeps non-blocking. `ci-ios` is separate for that reason. ## How it works 1. `ci-ios-plan` runs on the cheap default Linux stack. It derives the changed files, maps them through `e2e/config/ios_ci.yml`, and publishes one `CI_IOS_*` flag per job with `share-pipeline-variable@1`. Every macOS machine this pipeline boots is decided here, so a change needing no iOS job costs one short Linux build. 2. Each job workflow carries a `run_if` on its own flag. 3. `ci-ios-report` has **no** `run_if` and `should_always_run: workflow`. It posts the `Checkout Kit iOS` check run on every build, including one where the plan selected nothing. The `trigger_map` entry for `ci-ios` has no `changed_files` filter, on purpose. A required check that never posts leaves a pull request permanently unmergeable, so the trigger is unconditional and the cheap Linux gate decides the rest. ## Files | File | Role | | --- | --- | | `e2e/config/ios_ci.yml` | job → changed-file-filter mapping | | `e2e/lib/ios_ci_run_plan.rb` | selection, flag names, validation | | `e2e/lib/ios_ci_reporter.rb` | the `Checkout Kit iOS` check run | | `e2e/scripts/ios_ci_run_plan` | `validate` / `bitrise-env` / `selected-jobs` / `assert-pipeline-coverage` | | `e2e/scripts/report_ios_ci_results` | Bitrise entry point for the reporter | | `e2e/scripts/bitrise_ci_helpers` | changed-files, branch config, GitHub token — shared with the E2E gate | | `e2e/BITRISE.md` | the `ci-ios` section: why the trigger is unfiltered, why the check is self-posted | | `e2e/RUNBOOK.md` | "The iOS check failed or never posted", by symptom | ## Drift protection Three invariants in `e2e/test/ios_ci_run_plan_test.rb` assert set-equality between `ios_ci.yml`, the pipeline `run_if` expressions, and the `share-pipeline-variable@1` list, read from the real `e2e/bitrise.yml`. Adding a job to one side and not the others fails the suite. All three were confirmed red against a deliberately broken config before this was submitted. `ci-ios-plan` also runs `assert-pipeline-coverage` against the **branch head** `e2e/bitrise.yml`. Bitrise resolves the pipeline graph from the branch head while the plan is generated from the merged tree, so a stale branch can select a job whose workflow does not exist. This fails it fast with a rebase hint. ## Verification - `shadowenv exec -- ./scripts/test_ruby` — green. - `shadowenv exec -- bitrise validate --config=e2e/bitrise.yml` — valid. - CLI smoke tests for Swift-only, docs-only, and `e2e/bitrise.yml` changes. Still to do on a real build, per the plan: four probe pull requests — Swift-only, React Native-only, docs-only, and one touching `e2e/bitrise.yml`. `Checkout Kit iOS` must post on all four with the right pass/skip split. ## Decisions made without you - **Simulator**: settled on `iPhone 17 Pro` for every job. GitHub Actions used 17 Pro for Swift and 16 Pro for React Native; one `app.envs` value replaces the split. - **YAML anchor**: the `&macos_stack` definition moved to `ci-ios-swift-package-tests`, because YAML requires an anchor before its first alias and that workflow now comes first in document order. - **Beyond the plan text**: `e2e-report` and `e2e-produce-browserstack-run-plan` were refactored onto the new shared helpers, so the two gates cannot derive different changed-file lists from one commit. The `scripts` infra filter in `ci.yml` was widened to `e2e/config/**` *and* `e2e/bitrise.yml`. - **Docs land here, not in a separate PR**: the `BITRISE.md` and `RUNBOOK.md` sections describe this pipeline, so they ship with it. The stale `ruby: 3.3.6` in `BITRISE.md` is corrected to the actual `"3.4:installed"` in the same pass. ## Open question `ci-ios-report` needs a GitHub token. `e2e_export_github_token` falls back to the Bitrise GitHub App's `GIT_HTTP_PASSWORD`, which requires **Project settings → Repository → Extend GitHub App permissions to builds**. Please confirm that setting is on before the soak.
4a0efcf to
1473d71
Compare
61287b4 to
0941456
Compare

Part of the macOS CI speed-up
Epic
Issue
What
Adds a new
ci-iospipeline in bitriseci-ioswill be non-blocking until stable and will run in parallel to the github actionsci-ioswill run all macosxcodejobs to improve speedWhy
Bitrise reports one status per pipeline.
Reusing the
e2epipeline would tie the merge gate to the BrowserStack device flake thate2e/BITRISE.md:53deliberately keeps non-blocking.How it works
ci-ios-planruns on the cheap default Linux stack. It derives the changed files, maps them throughe2e/config/ios_ci.yml, and publishes oneCI_IOS_*flag per job withshare-pipeline-variable@1. Every macOS machine his pipeline boots is decided here, so a change needing no iOS job costs one short Linux build.run_ifon its own flag.ci-ios-reporthas norun_ifandshould_always_run: workflow. It posts theCheckout Kit iOScheck run on every build, including one where the plan selected nothing.The
trigger_mapentry forci-ioshas nochanged_filesfilter, on purpose.A required check that never posts leaves a pull request permanently unmergeable, so the trigger is unconditional and the cheap Linux gate decides the rest.
Files
e2e/config/ios_ci.ymle2e/lib/ios_ci_run_plan.rbe2e/lib/ios_ci_reporter.rbCheckout Kit iOScheck rune2e/scripts/ios_ci_run_planvalidate/bitrise-env/selected-jobs/assert-pipeline-coveragee2e/scripts/report_ios_ci_resultse2e/scripts/bitrise_ci_helpersBefore you merge
Important
platforms/swift/README.mdand/orplatforms/android/README.md)Releasing a new Swift version?
ShopifyCheckoutKit.podspecplatforms/swift/Sources/ShopifyCheckoutKit/ShopifyCheckoutKit.swiftplatforms/swift/README.md(major version only)Releasing a new Embedded Checkout Protocol version?
embeddedCheckoutProtocolAndroidinplatforms/android/gradle/libs.versions.tomlprotocol/languages/kotlin/embedded-checkout-protocol/api/embedded-checkout-protocol.apiif the public API changedReleasing a new Android version?
checkoutKitAndroidinplatforms/android/gradle/libs.versions.tomlplatforms/android/README.mdTip
See the Contributing documentation for the full release process per platform.