stages:
- setup #编译前环境配置
- oclint #objc 代码检查
- swiftlint #swift代码检查
- test #单元测试
- build #编译项目
- upload_pgy #上传到蒲公英
- upload_testflight #上传到testflight
- release #上传到appstore
variables:
LC_ALL: "en_US.UTF-8"
LANG: "en_US.UTF-8"
setup_job:
stage: setup
script:
- bundle install
tags:
- my-ios-gitlab-runner
oclint_job:
stage: oclint
script:
- bundle exec fastlane objectlint
artifacts:
paths:
- fastlane/oclint/objectlint.html
tags:
- my-ios-gitlab-runner
swiftlint_job:
stage: swiftlint
script:
- bundle exec fastlane swiftylint
artifacts:
paths:
- fastlane/swiftlint.html
tags:
- my-ios-gitlab-runner
test_job:
stage: test
script:
- bundle exec fastlane test
tags:
- my-ios-gitlab-runner
build_job:
stage: build
script:
- bundle exec fastlane build
tags:
- my-ios-gitlab-runner
upload_pgy_job:
stage: upload_pgy
script:
- bundle exec fastlane pgy_upload
artifacts:
paths:
- fastlane/pgy/*.ipa
tags:
- my-ios-gitlab-runner
upload_tf_job:
stage: upload_testflight
script:
- bundle exec fastlane tf_upload
artifacts:
paths:
- fastlane/tf/*.ipa
tags:
- my-ios-gitlab-runner
release_job:
stage: release
script:
- bundle exec fastlane release
tags:
- my-ios-gitlab-runner
only:
- tags
fastlane脚本
# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane
fastlane_require 'dotenv'
default_platform(:ios)
before_all do
Dotenv.overload '.env.secret'
Dotenv.overload '.env.default'
end
lane :objectlint do
oclint(
compile_commands: "compile_commands.json", # The JSON compilation database, use xctool reporter "json-compilation-database"
select_regex: /ViewController.m/, # Select all files matching this regex
exclude_regex: /Test.m/, # Exclude all files matching this regex
report_type: "html", # The type of the report (default: html)
report_path: "fastlane/oclint/objectlint.html",
max_priority_1: 8, # The max allowed number of priority 1 violations
max_priority_2: 9, # The max allowed number of priority 2 violations
max_priority_3: 10, # The max allowed number of priority 3 violations
thresholds: [ # Override the default behavior of rules
"LONG_LINE=200",
"LONG_METHOD=200"
],
enable_rules: [ # List of rules to pick explicitly
"DoubleNegative",
"SwitchStatementsDon'TNeedDefaultWhenFullyCovered"
],
disable_rules: ["GotoStatement"], # List of rules to disable
list_enabled_rules: true, # List enabled rules
enable_clang_static_analyzer: true, # Enable Clang Static Analyzer, and integrate results into OCLint report
enable_global_analysis: true, # Compile every source, and analyze across global contexts (depends on number of source files, could results in high memory load)
allow_duplicated_violations: true, # Allow duplicated violations in the OCLint report
extra_arg: "-Wno-everything"# Additional argument to append to the compiler command line
)
end
lane :swiftylint do
swiftlint(
reporter: "html",
output_file: "fastlane/swiftlint.html",
ignore_exit_status: true
)
end
lane :test do
scan(
scheme: ENV['XCODE_SCHEME'],
output_directory: "fastlane/tests",
clean: true
)
end
lane :build do
# incerment the build number
increment_build_number(
build_number: ENV['CI_JOBENV_ID'],
xcodeproj: ENV['XCODE_PROJECT']
)
# BUILD
gym(
scheme: ENV['XCODE_SCHEME'],
configuration: ENV['DEVELOP_CONFIGURATION'],
export_method: ENV['DEVELOP_EXPORT_METHOD'],
#export_xargs: ENV['DEVELOP_XARGS'],
silent: true,
clean: true,
codesigning_identity: "Apple Distribution: yangui xi (9S6T5CVY8R)",
export_options: {
provisioningProfiles: {
"com.xyg.fastlane" => "home_distrib"
}
}
)
end
lane :pgy_upload do
# incerment the build number
increment_build_number(
build_number: ENV['CI_JOBENV_ID'],
xcodeproj: ENV['XCODE_PROJECT']
)
build_app(
#workspace: "MyApp.xcworkspace",
configuration: "Debug",
scheme: ENV['XCODE_SCHEME'],
silent: true,
clean: true,
output_directory: "fastlane/pgy", # Destination directory. Defaults to current directory.
output_name: "pgy_debug.ipa", # specify the name of the .ipa file to generate (including file extension)
sdk: "iOS 15.2" # use SDK as the name or path of the base SDK when building the project.
)
pgyer(api_key: "10deff014b5276d83f1c368a662071d1", user_key: "b0bc3076c06dc48532eb58bb7b236b2d")
end
lane :tf_upload do
# incerment the build number
increment_build_number(
build_number: ENV['CI_JOBENV_ID'],
xcodeproj: ENV['XCODE_PROJECT']
)
gym(
clean: true,
output_directory: './fastlane/tf',
output_name:"testflight.ipa",
scheme: ENV['XCODE_SCHEME'],
configuration: ENV['DEVELOP_CONFIGURATION'],###########
include_bitcode: true,
include_symbols: true,
codesigning_identity:"Apple Distribution: yangui xi (9S6T5CVY8R)",
export_options: {
method: 'app-store',
provisioningProfiles: {
"com.xyg.fastlane" => "home_distrib"
},
}
)
notification(app_icon:"./fastlane/icon.png",title:"LoanManager",subtitle: "打包成功,已导出安装包>>>>>>>>", message: "准备发布中....")
api_key = app_store_connect_api_key(
key_id: "UU657JJ8N5",
issuer_id: "ffa427b7-d74d-4a21-8993-8f0477176e7d",
key_filepath: "./fastlane/AuthKey_UU657JJ8N5.p8",
duration: 1200, # optional (maximum 1200)
in_house: false # optional but may be required if using match/sigh
)
upload_to_testflight(
api_key: api_key,
skip_waiting_for_build_processing: true,
# username: "1xxxx@163.com",
# app_identifier: "com.sxx.xxx",
ipa: "./fastlane/tf/testflight.ipa",
skip_submission:true
)
end
platform :ios do
desc "Description of what the lane does"
lane :custom_lane do
# add actions here: https://docs.fastlane.tools/actions
end
end
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
Already a pro? Just edit this README.md and make it your own. Want to make it easy? Use the template at the bottom!
cd existing_repo
git remote add origin https://gitlab.com/XYGDeveloper/demo.git
git branch -M main
git push -uf origin main
Use the built-in continuous integration in GitLab.
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to makeareadme.com for this template.
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
Choose a self-explaining name for your project.
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
If you have ideas for releases in the future, it is a good idea to list them in the README.
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
Show your appreciation to those who have contributed to the project.
For open source projects, say how it is licensed.
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。