[DO NOT MERGE] Introduce swift version testing #513
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,7 +6,7 @@ | |
| agents: | ||
| queue: "mac" | ||
| env: | ||
| IMAGE_ID: $CURRENT_IMAGE_ID | ||
|
|
||
| steps: | ||
| ################# | ||
|
|
@@ -21,20 +21,56 @@ steps: | |
| ################# | ||
| # Build and Test | ||
| ################# | ||
| - group: "📦 Build and Test Swift Package" | ||
| steps: | ||
| - label: "📦 Build and Test Swift Package (Swift {{matrix.swift_version}})" | ||
| key: "test" | ||
| command: | | ||
| validate_swift_package test device_model:"{{matrix.device_model}}" os:"{{matrix.device_os}}" | ||
| plugins: [$CI_TOOLKIT] | ||
| env: | ||
| IMAGE_ID: "{{matrix.image_id}}" | ||
| matrix: | ||
| setup: # Specify the current version of Xcode, Swift, a device, and the required version of iOS | ||
| image_id: $CURRENT_IMAGE_ID | ||
| swift_version: $CURRENT_SWIFT_VERSION | ||
| device_model: $CURRENT_DEVICE | ||
| device_os: $CURRENT_OS | ||
| adjustments: # Specify additional versions of Xcode, Swift, a device, and the required version of iOS | ||
| - with: # Swift 5.9 | ||
| image_id: $SWIFT_5_9_IMAGE_ID | ||
| swift_version: $SWIFT_5_9_VERSION | ||
|
There was a problem hiding this comment. Given how YAML works, I expect that if If that's the case, and to prevent YAML from interpreting this as a float even if it looks like one and instead force it to interpret it as a string, you have two options:
The first option is probably easier to understand (and less surprising to people who don't know some advanced YAML techniques likes I'd suggest to apply the same rule (i.e. quoted strings) for other values as well, especially |
||
| device_model: $SWIFT_5_9_DEVICE | ||
| device_os: $SWIFT_5_9_OS | ||
| - with: # Swift 6.0 | ||
| image_id: $SWIFT_6_0_IMAGE_ID | ||
| swift_version: $SWIFT_6_0_VERSION | ||
| device_model: $SWIFT_6_0_DEVICE | ||
| device_os: $SWIFT_6_0_OS | ||
|
|
||
| ################### | ||
| # Validate Podspec | ||
| ################### | ||
| - group: "🔬 Validate Podspecs" | ||
| steps: | ||
| - label: "🔬 Validate Podspecs (Swift {{matrix.swift_version}})" | ||
|
There was a problem hiding this comment. Same as above, changing the name of the label will impact the name of the status check reported in GitHub PR that the |
||
| key: "validate" | ||
| command: | | ||
| .buildkite/commands/validate-pods.sh | ||
| plugins: [$CI_TOOLKIT] | ||
| env: | ||
| IMAGE_ID: "{{matrix.image_id}}" | ||
| matrix: | ||
| setup: # Specify the current version of Xcode and Swift | ||
| image_id: $CURRENT_IMAGE_ID | ||
| swift_version: $CURRENT_SWIFT_VERSION | ||
| adjustments: # Specify additional versions of Xcode and Swift | ||
| - with: | ||
| image_id: $SWIFT_5_9_IMAGE_ID | ||
| swift_version: $SWIFT_5_9_VERSION | ||
| - with: | ||
| image_id: $SWIFT_6_0_IMAGE_ID | ||
| swift_version: $SWIFT_6_0_VERSION | ||
|
|
||
| ####################### | ||
| # Publish the Podspecs (if we're building a tag) | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,5 +38,5 @@ | |
| } | ||
| } | ||
| ], | ||
|
There was a problem hiding this comment. This change (to There was a problem hiding this comment. Note: In addition to the {
+ "originHash" : "85a761808437c26b26a29368f9cc9aa509cdd039f95eff656309c72fa6ff2557"
# ...
+ "version" : 3
}That might be meaningful only in |
||
| "version" : 2 | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that changing the label of those jobs will have the side-effect of changing the name of the commit status event reported on the GitHub PR.
This PR targets
release/3.0.0which is not a protected branch, so doesn't have any required check, so this doesn't show here. But for PRs targetingtrunk, the branch protection settings requires thebuildkite/gravatar-sdk-ios/build-and-test-swift-packagecheck to pass… and with the new names of those CI jobs, such a check with that exact name won't exist anymore.So this means that once this PR lands and then is propagated to
trunk, you'll have to remember to update the branch protection settings of thetrunkbranch in GitHub to stop requiring the old check names and instead add the new ones instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the names of those checks emitted to GitHub are derived by Buildkite because we have the following settings set on the
gravatar-ios-sdkpipeline in Buildkite:If you don't like the names generated by Buildkite and find they are too verbose, we can disable this option (via our Infrastructure-as-Code setup for this pipeline and instead add the appropriate
notify: { github_commit_status: { context: "custom name" } }entry to each of the step we want a GitHub status to be reported for.The only "drawback" is that if we disable that setting for Buildkite to generate the commit statuses for us, we'll have to add the
notifyentry for every single step manually (i.e. we can't just customize some of them but let buildkite generate the status for the others). But that's still the approach we've tended to go towards in other pipelines lately (see: paaHJt-78h-p2), because custom status names are so much nicer to read in the UI of a Github PR than the generated oneLet us know if you want to go that route. You can already start adding the
notify: …blocks for each step to provide custom status names, and we can take care of disabling the ones generated by Buildkite once the custom ones fromnotify:land intrunkand we update the branch protection settings in GitHub accordingly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh, thank you!
Excellent, good idea.