Runs a custom script hosted at our private github
To add this step to your workflow, add this as a step in bitrise.yml:
- git::https://github.com/nodes-ios/bitrise-step-nodes-custom-script.git@master:
Be sure to select the correct input value for the script you want to run:
Parse project settings
Runs the parse_project_settings.rb
scriptFastlane copy
Copies the Fastfile into the /fastlane
directoryPrep Slack message
Runs the prepare_slack.rb
scriptThis script will create all the necessary steps on Bitrise (detailed bellow) to make the build.
There are 6 workflows, each with its own set of steps. The process works like this:
Most of these steps require custom scripts. These steps are written in Ruby and stored at nodes-ios/bitrise-step-nodes-custom-script. The Bitrise workflow will read from these scripts (currently at branch master
) so that your project will always build with the latest versions of the scripts.
Activating the SSH key for our private nodes-projects repo and cloning the project are handled automatically by bitrise. A changelog of the commit history between now and the previous tag is generated by a script maintained by nodes-android.
The first Nodes custom script happens next, which is the parse_project_settings.rb
script. The script is fairly well documented, but at a high level this is what happens: The project.yml file is loaded and parsed, as is the xcodeproj file, and the two are compared and validated to make sure information matches and all required settings exist. The values needed for building and uploading are saved as environment variables. The most likely step to fail here is hockey version number comparing. If the current project build number is the same as the version on hockey, validation will fail and your build will fail. Make sure to increment your build number before releasing a new tag!
This is mostly handeled by Bitrise. Cached build folder is loaded, carthage is built (using cached builds if possible), and then the cache is updated. If running locally using the Bitrise CLI, this step is skipped.
Building is handled by Fastlane. The Fastfile used here is loaded from the custom script step. The script copies the Fastfile
to the project directory for use in this step, as well as the two deploy steps.
For each target, the certificate and provisioning profile are retrieved from match
and installed, then the target is built, archived, and exported as a .ipa file. The target is then re-exported with bitcode turned off, because bitcode and enterprise profiles don't play nice together. match
grabs the enterprise cert and profile, and then that copy is resigned with the enterprise profile and certificate for uploading to Hockey. Then the upload info is saved as an environment variable.
Also handled by Fastlane, and it uses the same Fastfile as in the build step. This step is fairly straightforward: The deploy configuration from the build step is loaded, and used to upload directly to Hockey. Note that this step will be skipped if hockey-upload
is disabled in the project.yml file.
Also handled by Fastlane, using the same Fastfile. Again, this step is straightforward and is basically indentical to the Hockey upload step. It will be skipped if testflight-upload
is disabled in the project.yml file.
Note that your build may fail here if you have not incremented your build number since the last Testflight upload.
The first thing that is notified is github, this is what confirms that the build passed, if something was waiting on the status before proceeding.
The final custom script is next, which aggregates all of the build information into one message for slack to display, including the scheme (target name, basically), configuration (Adhoc/Release), version number, and Hockey link. There will also be a note that a Testflight build will be available after processing.