パッケージごとにbuild numberを自動的に追加

新しいニーズは、テスト環境がパッケージ化されるたびにbuild numberを増加させ、現在のテスト環境パッケージはgitlab ci+fastlane+fir-cliを通過し、テストはfirを通じてダウンロードされ、生産または準生産環境はtestflightにパッケージ化されてテストされていることを示しています.

生産環境&準生産

testflightは同じバージョンでアップロードされるたびにbuildが以前と異なる必要があるため、testflight対応バージョンの最近のbuild numberを引き上げればいいのですが、testflightではすぐにダウンロードできないのが欠点で、待つ必要があるので、この時間帯は最新のbuild numberに引き寄せることができず、private laneを追加することができません

desc "Update build number to next one available"
  private lane :update_build_number do
    increment_build_number({
      build_number: latest_testflight_build_number(version: get_version_number) + 1
    })
 end

テスト環境

firにパブリッシュしてテストを行うので、build numberは実際に繰り返すことができます.

シナリオ1、build numberとcommitを1回追加

実はfastlaneの上の支持はすでにとても良くて、commit_version_bump actionが自動的にcommitに来て1回のversion bumpに来て、increment_build_numberに協力して効果はとても良くて、しかしgitlab runnerの上でパッケージングを行うので、毎回すべてcheckoutが1回現在パッケージングして分岐して、だからbuild numberの記録を行うことができなくて、少しがっかりします

シナリオ2、グローバル・バージョン・レコードに基づく

一つのversionでlogファイルは、Ruby(NSDictionaryと同様)へのアクセスが便利であるため、バージョンごとに対応するbuild number更新を記録する.欠点はpipelineの実行中にバージョンを追加してキャンセルし、バージョンを追加することです.しかし、影響は大きくなく、繰り返さなければいいです.

 private lane :add_local_build_number do
    path = "./version_log"
    a_file =  File.open(path, 'r+')
    line = a_file.readlines
    version = get_version_number(xcodeproj: "./xcode.xcodeproj")
    dic = line.count > 0 ? eval(line[0]) : {}
    a_file.close
    puts dic
    dic[version] = dic[version].to_i + 1
    build_number = dic[version]
    b_file = File.open(path, 'w')
    b_file.syswrite(dic.to_s)
    b_file.close
    increment_build_number({
      build_number: build_number
    })
  end

シナリオ3:firの上のバージョン情報を引いてbuild+1を行う

apiアドレスは、より正確なバージョンが追加されます
2、hashとfastlaneに改めて感謝して、時間を節約しました.