Skip to content

Conversation

bacarybruno
Copy link

@bacarybruno bacarybruno commented Sep 8, 2025

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 in action.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.

@thymikee
Copy link
Contributor

thymikee commented Sep 9, 2025

Looks good! How can we test this? Do you have a sample repo you could share?

@bacarybruno
Copy link
Author

I tested it manually by creating a new rock project, but I can prepare a sample repo yes 👍

@bacarybruno
Copy link
Author

Hello again!

I tested using this workflow file: bitrise.yml.

Screenshot 2025-09-09 at 20 20 32

It works, but I had to create a dedicated repository to host the Bitrise workflow: bitrise-rock-remote-build-ios, since Bitrise requires the step.yml file to be at the repository root.

So now we have two possible approaches:
1️⃣ Move step.yml and step.sh to the root of the current repo.
2️⃣ Keep a dedicated repo just for the Bitrise workflow.

Which option do you think we should go with? Or do you see another possible solution?

@thymikee
Copy link
Contributor

If possible, I'd keep the code colocated. Especially if we could reuse some of these shell scripts

@thymikee
Copy link
Contributor

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

@bacarybruno
Copy link
Author

bacarybruno commented Sep 10, 2025

If possible, I'd keep the code colocated. Especially if we could reuse some of these shell scripts

Good point, I updated the PR to move the bitrise step to the repository root + tested the workflow on rock-remote-build-test.

@bacarybruno
Copy link
Author

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.
After this PR I'll do the same for Android, then maybe the website will also need to be updated.

@bacarybruno
Copy link
Author

fyi in a follow-up PR, I plan to introduce a Bitrise remote cache provider that handles saving and restoring the .rock folder. The main limitation is retrieval in local environments: it’s possible to fetch cache items through the Bitrise API but there’s no server-side filtering. We would need to paginate through the available entries and filter them client-side until the right one is found. https://docs.bitrise.io/en/bitrise-ci/api/api-reference.html#operations-tag-key-value-cache

And also we can't upload programmatically. For that maybe I can do something like this :

ios/action.yml

Line 308 in 08a533d

if: ${{ env.PROVIDER_NAME == 'GitHub' && (!env.ARTIFACT_URL || (inputs.re-sign == 'true' && github.event_name == 'pull_request')) }}

@thymikee
Copy link
Contributor

We would need to paginate through the available entries and filter them client-side until the right one is found. https://docs.bitrise.io/en/bitrise-ci/api/api-reference.html#operations-tag-key-value-cache

This is fine, if there's no other way, should still be pretty fast to retrieve available artifacts

And also we can't upload programmatically. For that maybe I can do something like this

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)"
Copy link
Contributor

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

Copy link
Author

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
Comment on lines 113 to 131
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"
Copy link
Contributor

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

Copy link
Author

@bacarybruno bacarybruno Sep 14, 2025

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?

Copy link
Author

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

Copy link
Author

@bacarybruno bacarybruno Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and completed here 6db3bdd

Copy link
Contributor

@thymikee thymikee left a 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))"
Copy link
Contributor

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:

Suggested change
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))

Copy link
Author

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated here 395dd01

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants