Allow integration_tests workflow to run against a packaged SDK. #323
Conversation
set the matrix target to "openssl" but just treat it like boringssl later.
(workflow_dispatch only works on branch names, not commit IDs.) Add error checking to GitHub API request.
This reverts commit 6cddf78.
jonsimantov requested review from DellaBitta and a-maurice and removed request for DellaBitta and a-maurice to securely identify the correct workflow you triggered.
…be used" This reverts commit 5e69207.
| The expanded matrix was meant to also expand the build configurations we use, including building across multiple XCode targets, which we do in some other workflows. I thought this was important for our packaging workflows, too, and in my head this would have complicated the script. But now I'm realizing that we only ship one version of the packaged SDK, so why would our CI build multiple Xcode versions of it, etc. Is this your philosophy, too? |
| hashCommand: "sha256sum" | ||
| # Xcode version 12 is the version we build the SDK with. | ||
| # Our MacOS runners will use the version in /Applications/Xcode_${xcodeVersion}.app | ||
| xcodeVersion: "12" |
There was a problem hiding this comment.
You can remove this env now.
There was a problem hiding this comment.
It's still needed, because it controls what xcode version the SDK is built with.
There was a problem hiding this comment.
The code sudo xcode-select -s /Applications/Xcode_${{ env.xcodeVersion }}.app/Contents/Developer has been removed below. Is there something else in here that uses it? Some silent GHA observance of the variable?
That was my thought. We build and ship the binary SDK in a single set of configurations. I am happy to keep the SDK packaging matrix in this workflow, and the test matrix in the script. The packaging matrix should never change in the normal course of development. |
2 participants
This change updates the integration_tests workflow so that it can download a packaged SDK from GHA and build the integration tests against it, instead of against the SDK source.
With that change, we no longer need to duplicate the integration test code in the C++ packaging workflow.
Instead, the C++ packaging workflow directly invokes the integration_tests workflow at the end via the GitHub REST API.
(Note that because you cannot invoke another workflow with the same GITHUB_TOKEN that your workflow is already using due to a limitation in GitHub actions, the packaging workflow fetches a new GitHub App token to use for the request.)