-
Notifications
You must be signed in to change notification settings - Fork 3
feat: create bitrise step #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Looks good! How can we test this? Do you have a sample repo you could share? |
I tested it manually by creating a new rock project, but I can prepare a sample repo yes 👍 |
Hello again! I tested using this workflow file: bitrise.yml. ![]() It works, but I had to create a dedicated repository to host the Bitrise workflow: bitrise-rock-remote-build-ios, since Bitrise requires the So now we have two possible approaches: Which option do you think we should go with? Or do you see another possible solution? |
If possible, I'd keep the code colocated. Especially if we could reuse some of these shell scripts |
I've invited you to our internal repo for testing Rock's remote builds: https://github.com/callstack-internal/rock-remote-build-test/. I think we should make it public soon, and it could be our test bed for CI workflows we support |
Good point, I updated the PR to move the bitrise step to the repository root + tested the workflow on rock-remote-build-test. |
Hello @thymikee the PR is ready as I just updated the readme. Please don't hesitate to ping me if you think there is still something missing. |
fyi in a follow-up PR, I plan to introduce a Bitrise remote cache provider that handles saving and restoring the And also we can't upload programmatically. For that maybe I can do something like this : Line 308 in 08a533d
|
This is fine, if there's no other way, should still be pretty fast to retrieve available artifacts
Makes sense, if there's no other API (same for GitHub) |
step.sh
Outdated
ARTIFACT_TRAITS="${DESTINATION},${CONFIGURATION},${BITRISE_PULL_REQUEST:-}" | ||
envman add --key ARTIFACT_TRAITS --value "$ARTIFACT_TRAITS" | ||
|
||
OUTPUT="$(npx rock remote-cache list -p ios --traits "${ARTIFACT_TRAITS}" --json || true)" |
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.
not sure about the || true
part. The reason we do || (echo "$OUTPUT" && exit 1)
is for escaped shell commands, such as ${npx rock remote-cache ...)
here to show error output when they fail and exit
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.
Updated here 374ceb8
step.sh
Outdated
KEYCHAIN_PATH="$RUNNER_TEMP/app-signing.keychain-db" | ||
|
||
security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH" | ||
security set-keychain-settings -lut 21600 "$KEYCHAIN_PATH" | ||
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH" | ||
|
||
CERTIFICATE_PATH="$RUNNER_TEMP/certificate.p12" | ||
echo -n "$CERTIFICATE_BASE64" | base64 --decode -o "$CERTIFICATE_PATH" | ||
security import "$CERTIFICATE_PATH" -P "$CERTIFICATE_PASSWORD" -A -t cert -f pkcs12 -k "$KEYCHAIN_PATH" | ||
security set-key-partition-list -S apple-tool:,apple: -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH" | ||
security list-keychain -d user -s "$KEYCHAIN_PATH" | ||
|
||
IDENTITY="$(security find-identity -v -p codesigning "$KEYCHAIN_PATH" | grep -oE '([0-9A-F]{40})' | head -n 1 || true)" | ||
echo "Certificate identity: $IDENTITY" | ||
envman add --key IDENTITY --value "$IDENTITY" | ||
|
||
mkdir -p "$PROFILE_DIR" | ||
PROFILE_PATH="$PROFILE_DIR/$PROVISIONING_PROFILE_NAME.mobileprovision" | ||
echo -n "$PROVISIONING_PROFILE_BASE64" | base64 --decode -o "$PROFILE_PATH" |
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.
is this the recommended way to process provisioning profiles on Bitrise? we followed the recommendation for GitHub, but just want to make sure this is ok
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.
There are many ways to handle this. Some projects like ours use Fastlane, others rely on one of the recommended options, or even custom setups etc. I’m wondering if we should let each project manage its own signature setup, and simply pass the --identity
flag value to the workflow instead.
What do you think about it?
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.
That would look like this b578ca1
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.
and completed here 6db3bdd
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.
This looks pretty good already, just small nits 👍🏼
step.sh
Outdated
ARTIFACT_TRAITS="${DESTINATION},${CONFIGURATION},${BITRISE_PULL_REQUEST:-}" | ||
envman add --key ARTIFACT_TRAITS --value "$ARTIFACT_TRAITS" | ||
|
||
OUTPUT="$(npx rock remote-cache list -p ios --traits "${ARTIFACT_TRAITS}" --json || (echo "$OUTPUT" && exit 1))" |
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.
OUTPUT needs to evaluate, so we can't wrap everything with "
quotes. In GHAction we're using this syntax, I think it should work:
OUTPUT="$(npx rock remote-cache list -p ios --traits "${ARTIFACT_TRAITS}" --json || (echo "$OUTPUT" && exit 1))" | |
OUTPUT=$(npx rock remote-cache list -p ios --traits "${ARTIFACT_TRAITS}" --json || (echo "$OUTPUT" && exit 1)) |
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.
Oh right, thanks I'll update
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.
Updated here 395dd01
Context: callstack/rock#552
This PR adds the initial version of the Rock Bitrise workflow.
It is largely based on the existing GitHub Actions workflow, which also served as the reference for the
step.sh
script.At this stage,
step.sh
duplicates some of the logic defined inaction.yml
.In future iterations, we can consider extracting the common functionality into a shared script or library so that both Bitrise and GitHub workflows can consume the same code and stay in sync.
Documentation will follow once we align on this PR.