Fixes#76033
The benchmarking code in the iOS TestApp was removed a while back as dead code:
https://github.com/pytorch/pytorch/pull/64849
I believe this was done in error - as this leaves our TestApp empty, nothing occurs when it runs. And we still have a tutorial up demonstrating how to use the benchmarking feature of the TestApp.
This diff restores the files that were deleted, with some minor tweaks for compatibility with changes that have happened since they were deleted.
Pull Request resolved: https://github.com/pytorch/pytorch/pull/85539
Approved by: https://github.com/kimishpatel
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/30327
### Summary
Seems like starting from macOS 10.15, we can no longer get access to the `Downloads` folder in our macOS machines.
```
permissionError: [Errno 1] Operation not permitted: '/Users/distiller/Downloads'
```
The fix is to change the conda download directory to ${HOME}
### Test Plan
- iOS jobs are back to normal
- Don't break other jobs
Test Plan: Imported from OSS
Differential Revision: D18717380
Pulled By: xta0
fbshipit-source-id: cad754076bf4ae5035741aa57a310ad87c76726e
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/30133
### Summary
Recently we've found that the master branch was constantly broken due to some unwanted change being landed on mobile. The problem is that our CI was not able to detect the runtime errors.
### Previous work
- Add an unit test target to the iOS TestApp ( #29962 )
- Update Fastlane to run tests ( #29963 )
### What's been changed in CI
1. XCode version has been updated to 11.2.1
2. For iOS simulator build, we'll run some unit tests( currently only one) after the build test.
Test Plan: Imported from OSS
Differential Revision: D18641413
Pulled By: xta0
fbshipit-source-id: 12942206f1dee045b2addba3ae618760e992752c
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/29962
### Summary
Recently we've found that the master branch was constantly broken due to some unwanted change being landed on mobile. The problem is that our CI was not able to detect the runtime errors. Starting from this PR, we'll add some unit tests to the iOS Simulator build. As follows:
1. Add an unit test target to XCode (this PR)
2. Use Fastlane to run the tests on CI
3. Modify the CI scripts to trigger tests
### Test Plan
- Don't break the existing CI jobs unless they are flaky.
Test Plan: Imported from OSS
Differential Revision: D18582908
Pulled By: xta0
fbshipit-source-id: f960c47d3bbda79e754a0513e8711867fd3588d2
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/28405
### Summary
As discussed with AshkanAliabadi and ljk53, the iOS TestApp will share the same benchmark code with Android's speed_benchmark_torch.cpp. This PR is the first part which contains the Objective-C++ code.
The second PR will include the scripts to setup and run the benchmark project. The third PR will include scripts that can automate the whole "build - test - install" process.
There are many ways to run the benchmark project. The easiest way is to use cocoapods. Simply run `pod install`. However, that will pull the 1.3 binary which is not what we want, but we can still use this approach to test the benchmark code. The second PR will contain scripts to run custom builds that we can tweak.
### Test Plan
- Don't break any existing CI jobs (except for those flaky ones)
Test Plan: Imported from OSS
Differential Revision: D18064187
Pulled By: xta0
fbshipit-source-id: 4cfbb83c045803d8b24bf6d2c110a55871d22962
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/27591
## Summary
Since the nightly jobs are lack of testing phases, we don't really have a way to test the binary before uploading it to AWS. To make the work more solid, we need to figure out a way to verify the binary.
Fortunately, the XCode tool chain offers a way to build your app without XCode app, which is the [xcodebuild](https://developer.apple.com/library/archive/technotes/tn2339/_index.html) command. Now we can link our binary to a testing app and run `xcodebuild` to to see if there is any linking error. The PRs below have already done some of the preparation jobs
- [#26261](https://github.com/pytorch/pytorch/pull/26261)
- [#26632](https://github.com/pytorch/pytorch/pull/26632)
The challenge comes when testing the arm64 build as we don't have a way to code-sign our TestApp. Circle CI has a [tutorial](https://circleci.com/docs/2.0/ios-codesigning/) but is too complicated to implement. Anyway, I figured out an easier way to do it
1. Disable automatically code sign in XCode
2. Export the encoded developer certificate and provisioning profile to org-context in Circle CI (done)
3. Install the developer certificate to the key chain store on CI machines via Fastlane.
4. Add the testing code to PR jobs and verify the result.
5. Add the testing code to nightly jobs and verify the result.
## Test Plan
- Both PR jobs and nightly jobs can finish successfully.
- `xcodebuild` can finish successfully
Test Plan: Imported from OSS
Differential Revision: D17844036
Pulled By: xta0
fbshipit-source-id: 741f0442a718c9bda706107a2c4c3baed4c37137
Summary:
ignore the folder and its children ios/TestApp
Pull Request resolved: https://github.com/pytorch/pytorch/pull/26399
Differential Revision: D17451239
Pulled By: houseroad
fbshipit-source-id: d6ba666bf955454eca4a10c00784ee5947a70f59
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/26261
### Summary
Previously we have enabled the CI jobs for Pull Requests and nightly build
- **#25840 [iOS][Circle CI] Add PR jobs for iOS builds**
- **#26074 [IOS][CIRCLE CI] Nightly jobs for iOS builds**
The testing phase is missing in the nightly build process. Although we are able to generate the build and upload it to the AWS, there is no way to know whether the binary is valid or not (there could be a linking error). To add the test phase to the process, we need
1. Put a dummy test App in the repo.
2. After the build jobs finishes, manually link the static libs to the dummy app to produce an executable using the xcode tool chain.
3. If there is no linking error, then upload the binaris to AWS. If there is an error, then stops the following process and reports an error in CI.
The second and third steps depends on the first step which needs to be landed first.
### Test Plan
- Don't break any existing CI jobs
Test Plan: Imported from OSS
Differential Revision: D17408929
Pulled By: xta0
fbshipit-source-id: e391da242639943005453d1318795f981034cc72
