Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other tha
Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other than zsh and bash. this pr find a new way to deal with xcode building issues that it cannot find the correct nodejs path. close ENG-4864 close ENG-5242 # How react-native introduces `.xcode.env` and `.xcode.env.local` for developers to override the `$NODE_BINARY`: https://github.com/facebook/react-native/pull/33546 to make sure building success from expo-constants, expo-updates, and also the app target when generating bundles. i would like to reuse the `.xcode.env` and `.xcode.env.local` from react-native. this pr further generates `.xcode.env.local` automatically for the app during `pod install`. we can ensure that `pod install` is executed from shell and nodejs is available. so we will generate `export NODE_BINARY="$(command -v node)"` in the `.xcode.env.local`. for xcode, the path will be `$PODS_ROOT/../.xcode.env.local`, every xcode subprojects can source the file to get correct `$NODE_BINARY`. # Test Plan - building bare-expo from xcode (opening xcode by macos finder) - building bare-expo by `yarn ios` - updates e2e ci passed - building expo-go (prerequisite: #18344) Co-authored-by: James Ide <[email protected]>
show more ...
Remove CircleCI config and bins (#11971)
Remove remains of Nix (#11989)
[tools] Move tools/expotools one folder up (#11410)
Add xcpretty binstub
Make the fastlane binstub executable
[ci] Trigger release jobs with workflow_dispatchThis makes a button appear in the github ui to run the workflow onwhatever branch you want.
[repo] Upgrade CocoaPods and Fastlane (#8560)# Why When running `git pull` I noticed a strangely long output mentioning a lot of new `.xcconfig`s so I went to see when and why they were added. T
[repo] Upgrade CocoaPods and Fastlane (#8560)# Why When running `git pull` I noticed a strangely long output mentioning a lot of new `.xcconfig`s so I went to see when and why they were added. The commit adding them was [Publish expo-permissions, expo-notifications](https://github.com/expo/expo/commit/264a8722e01eb91cf1ec20eb5bdd09dd26fb829d). This does not sound like a commit that willingly upgrades CocoaPods used throughout the repository (which it did), so I decided to: - fix the long-standing problem of `pod` being used not-from-the-bundle - upgrade CocoaPods and Fastlane while I'm at it # How - updated version requirement for CocoaPods to `~> 1.9.1` - had to run `gem install bundler:2.1.4` even though I thought I've already run this command some time before - ran `bundle install` to install new CocoaPods - updated version requirement for Fastlane to `~> 2.148.0` - ran `bundle install` to install new CocoaPods - added `pod` and `fastlane` executables to the `bin` directory that are similar to `lock` executable—they are like an alias that makes `pod <X>` resolve to `bundle exec pod <X>` which should ensure that `pod` commands will fail if they would not resolve to the version installed by the bundler (In fact, `bundle install` installs its own executable commands under `.direnv/bin/`, but… you first have to run `bundle install` to have them, fail on `bundle exec pod…` should make it clear for the developers to install pods this way.) This commit also updates Pods of `react-native-safe-area-context` in `bare-expo`. # Test Plan - Ran `where pod`, verified that `/Users/sjchmiela/Applications/expo/bin/pod` is on the list. - Ran `bundle exec pod install` in `ios`, verified that it installs pods properly - Ran `pod install`, verified that it installs pods properly
[ci] Create `bin/github-repository-dispatch`This command creates Repository Dispatch events on the expo/exporepository which GitHub Action workflows can listen for.This makes it possible to crea
[ci] Create `bin/github-repository-dispatch`This command creates Repository Dispatch events on the expo/exporepository which GitHub Action workflows can listen for.This makes it possible to create release workflows for arbitrary gitreferences.The usage is `bin/github-repository-dispatch EVENT_TYPE GIT_REFERENCE`So for example `bin/github-repository-dispatch foo bar` will send thisevent:```{ "event_type": "foo", "client_payload": { "ref": "bar" }}```
[tools] Remove expo-cli as a dependency of the workspace root (#8316)Having expo-cli in the shared workspace dependency is preventing us from upgrading to TS 3.9 because it indirectly depends on TS
[tools] Remove expo-cli as a dependency of the workspace root (#8316)Having expo-cli in the shared workspace dependency is preventing us from upgrading to TS 3.9 because it indirectly depends on TS 3.8. Specifically, expo-cli should not be pulling in TS. More generally, expo-cli indirectly depends on a lot of packages and Yarn workspaces + Metro are fragile when we have multiple dependencies with different versions. We've seen issues with multiple versions of Babel, React Navigation, and now TypeScript. expo-cli was first added as a dependency of the root package.json along with the bin stubs. This was so that the whole repo was using the same version of Expo CLI. While I think this is very good, Having it be a dependency of the workspace root is problematic. If we would like expo-cli installed and to restore the bin stubs, we could either make a separate dummy package that installs expo-cli or rely on a global copy and check its version. The important thing is that expo-cli is not a workspace dependency. Looked through the CI config files and didn't see anything call into `expo`. Ran `expo --version` and ensured it matched the version of Expo CLI installed by expotools.
[ci] Don't run normal workflows in release pipelines
[ci] Control shell and client releases with circle-run-pipeline
[ios][ci] Control simulator releases with circle-run-pipeline
[android][ci] Control releases with circle-run-pipeline
Add bin/circle-run-pipeline
[ci] skip_unless_changed is resilient to api failures`bin/circle-last-successful-commit` exits in failure when the circle apiis unreachable for any reason. Without this change, this causes thebu
[ci] skip_unless_changed is resilient to api failures`bin/circle-last-successful-commit` exits in failure when the circle apiis unreachable for any reason. Without this change, this causes thebuild to fail. With this change, the normal fallback of`pipeline.git.base_revision` is used.
[ci] Skip unchanged jobs on master
Remove nix
Update npm binstub to 6.14.3 (#7779)* bin/np{m,x} use nodePackages.npm * Update nix pin
[tools] Prevent from checking whether google-services.json is present in bare-expo app. (#6931)* [tools] Prevent from checking whether google-services.json is present in bare-expo app.
[nix] Update dependencies (#6346)# Why 1. We've been using not-latest, beta version of CocoaPods for a while. 2. New Yarn version was available. # How Ran `./update-dependencies`, reinsta
[nix] Update dependencies (#6346)# Why 1. We've been using not-latest, beta version of CocoaPods for a while. 2. New Yarn version was available. # How Ran `./update-dependencies`, reinstalled pods in both `ios` and `bare-expo/ios`. # Test Plan Both projects should build.
Delete leftover sandbox-pod binstub
[ios] Enable CocoaPods 1.8 improvements (#5502)# Why Closes https://github.com/expo/expo/issues/4667. # How - upgraded CocoaPods to 1.8.0.beta1 - enabled CocoaPods improvements - grouped
[ios] Enable CocoaPods 1.8 improvements (#5502)# Why Closes https://github.com/expo/expo/issues/4667. # How - upgraded CocoaPods to 1.8.0.beta1 - enabled CocoaPods improvements - grouped offending Facebook dependencies together so they can access each other # Test Plan Expo client builds and runs ok
`./update-dependencies`
[expotools] throw nix out of expotools �� (#4469)# Why Preparing the ground to #4428 As far as I know there is no need to utilize nix packages in expotools, however this was always a pain for
[expotools] throw nix out of expotools �� (#4469)# Why Preparing the ground to #4428 As far as I know there is no need to utilize nix packages in expotools, however this was always a pain for us since this takes so much time before we can run any command. To be honest I usually run expotools directly from `tools/expotools/bin/expotools.js` to omit nix. # How - Removed nix from expotools stub - can we open a champagne already? �� - Added a wrapper around expotools that ensures build and node_modules folders are up to date - Made asorted improvements in the output of expotools commands Screenshot: <img width="1178" alt="Screenshot 2019-06-07 at 00 22 13" src="https://user-images.githubusercontent.com/1714764/59070333-abda0f00-88ba-11e9-9d9d-a5fdbbec0315.png"> # Test Plan Tried some different commands with different flags to cover all use cases.
12