Fastlane Fastfile #3

:  ~ 2 min read

In the previous post we stopped at incrementing the build number. Now let's talk about the completion. The process is a bit big, but we'll go through it, step by step:

after_all do |lane|
  # Sometimes I just want to test some stuff, so I don't want to post anything on slack
  if lane == :test; clean; next; end
  type = lane == :hockey_debug ? 'Debug' : 'Release'
  # time =
  slack_params = {
    message: 'iOS App successfully released to Hockey!',
    payload: {
      # 'Date' => "#{t.year}-#{t.month}-#{} #{t.hour}:#{t.min} (#{})",
      # Because we increase the version after each build,
      # but submit before the increase
      'Build' => "#{build_number.to_i - 1}",
      'Version' => version_number,
      'Type' => type
    default_payloads: [:git_branch, :git_author, :last_git_commit]
  if release_lane lane
    slack_params[:message] = 'iOS App successfully submitted to the App Store!'
    slack_params[:payload]['Download Link'] = "#{Actions.lane_context[Actions::SharedValues::HOCKEY_DOWNLOAD_LINK]}"
  slack slack_params

error do |lane, exception|
  if release_lane(lane)

def clean
  # Don't clear provisioning profiles, as we store them in git
  clean_build_artifacts exclude_pattern: ".*\.mobileprovision"

def release_lane(lane)
  lane.to_s.include? 'release'

def revert_version
  Shenzhen::PlistBuddy.set plist, 'CFBundleShortVersionString', @previous_version

And the flow would be: after the lane has finished, check if it was a debug lane or not, so we create a proper message and a download link for Debug and Beta builds, create the hash to be sent to Slack, do the required git changhes and clean all artifacts except the mobileprovision files. If the lane failed, revert the version and clean.

The git handling method looks like this:

def commit_tag_and_update_release_branch 'git add .' "git commit -am \"Version Bump to #{version_number}\"" "git tag -a #{version_number} -m \"Version #{version_number} submitted to the App Store\""
  # Earlier we already set ensure_git_branch to development, unless we used the :release_quick_fix lane
  # So we know we either are on the development branch, or on a quick-fix one, so it's safe to push and pull-request "git push origin #{current_branch}:#{current_branch}" "git pull-request -m \"Merging #{version_number}\" -b development -h release"

It commits the version bump we did earlier with increase_version, tags the commit with the version_number, pushes the branch and opens a pull request (with the help of hub, a command line wrapper for GitHub).

In the next and final post, Deliverfile.