-
Notifications
You must be signed in to change notification settings - Fork 24.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CI] Migrate to Circle 2.0 #14955
[CI] Migrate to Circle 2.0 #14955
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is that it'll be hard to write a working YAML file the first time, might be easier to incrementally work on it in this PR.
.circleci/config.yml
Outdated
version: 2 | ||
jobs: | ||
build: | ||
machine: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CircleCI stopped recommending the machine
key and said they might charge for it. I don't think we need a machine executor since we're not using docker-compose. I think we want to use the Java 8 image (circleci/openjdk:8-jdk) and then install Node separately or add a new build to the workflow that uses the Node image to build the website in parallel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've been using workflows with separate images (in particular, testing on different Node versions, just like Travis does by default) and it's been working well. Not sure about performance disadvantages though.
.circleci/config.yml
Outdated
steps: | ||
- checkout | ||
- restore_cache: | ||
key: react-native |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about splitting the cache up more granularly, one key for each of the four directories being cached? This way we can invalidate the cache in a more fine-grained way too.
.circleci/config.yml
Outdated
cd website && npm install | ||
|
||
- save_cache: | ||
key: react-native |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a version to the cache keys (just prefix with "v1-") so we can invalidate them by hand easily? Also for node_modules
and website/node_modules
, how about separate caches where each key name contains {{ checksum "package.json" }}
?
.circleci/config.yml
Outdated
- save_cache: | ||
key: react-native | ||
paths: | ||
- "ReactAndroid/build/downloads" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the list of RN downloads changes we'll want the key to invalidate itself. Perhaps we should include the checksum of one of the Gradle files in a cache key.
.circleci/config.yml
Outdated
#find . -type f -regex ".*/buck-out/gen/ReactAndroid/src/test/.*/.*xml" -exec cp {} $CIRCLE_TEST_REPORTS/junit/ \; | ||
|
||
- deploy: | ||
branch: [/.*-stable/, /master/] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this syntax is supported anymore since the CircleCI docs say to check the branch name in the command
section manually.
.circleci/config.yml
Outdated
# CIRCLE_NPM_TOKEN is in React Native project settings in Circle CI. | ||
# It was generated for bestander user, easy to replace with anyone's else | ||
echo "//registry.npmjs.org/:_authToken=${CIRCLE_NPM_TOKEN}" > ~/.npmrc | ||
npm config set spin=false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll need to install Node before this, probably need to get nvm first
Not sure it's worth it, but one small tweak that I've applied when migrating was to take advantage of |
I think that CI's speed-up will contribute to improving the progress of the project and I update my favorite projects to CircleCI 2.0. I want to work on this issue together. How do I proceed? |
@serima I don't think I'll get back to this PR for some time as this month is pretty busy for me, but any PR opened against this repo should trigger a CI run. You can start fresh or use this PR as a base, and open a new PR with your changes. There's several things running on Circle, so a successful PR will need to ensure every test is covered, including website deployment and publishing to npm. |
Hi, @hramos, I see. Thank you. |
Had some extra time between tasks today. Instead of migrating all of the old tests over, I'll handle them one by one. Hopefully I'll have more time to dig into this tomorrow. My plate is quite full at the moment and I was not planning on working on this just yet, but it may be necessary in order to test multiple Node versions concurrently. |
.circleci/config.yml
Outdated
steps: | ||
- checkout | ||
- restore-cache: *restore-cache | ||
- npm install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need this to be behind the run:
key. Also might want to add --no-package-lock
since npm 5 adds package-lock.json.
.circleci/config.yml
Outdated
test-node-8: | ||
working_directory: ~/react-native | ||
docker: | ||
- image: circleci/node:8.1.4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of just making this be circleci/node:8
so we naturally test the latest version of 8.x (but give up some reproduceability)?
.circleci/config.yml
Outdated
npm run flow -- check | ||
npm test -- --maxWorkers=1 | ||
test-node-4: | ||
working_directory: ~/jest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be ~/react-native like the others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should! I followed Jest's as a starting point, and I overlooked this line.
.circleci/config.yml
Outdated
aliases: | ||
- &restore-cache | ||
keys: | ||
- dependencies-{{ .Branch }}-{{ checksum "package.json" }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you prefix all the keys with v1-
so we can easily manually bust the cache if we need to?
I'm also concerned about sharing node_modules caches across npm versions. In particular, Node 4 comes with npm 2 which doesn't have the deduping functionality of npm 3+.
What if we didn't cache node_modules for react-native but continued to cache them for the website and danger (where we use just a single Node + npm version)?
Thank you very much. The point of @ide's code review seems very appropriate. After that, it takes time to repeat trial and error. |
…se Node 8, s/jest/react-native/
Yup, this has been helpful. I had to push out the previous commit earlier before I had to run. Taking another stab at doing some basic JS tests tonight. |
Lints and basic tests are working on Node 6 and 8. npm install failed on 4 as expected. Having all the individual workflow results listed here on GitHub is very useful, and should help us get better signal even when some tests are broken. |
Forgot to mention: caching is in place in various places, which should significantly speed up the build! |
Failures are in the Animated library, I suspect it's because our AVD is launched with no hw accel. |
Looks like starting the emulator like so should fix this, but I am getting a segfault:
This post on SO has more info. I’ll continue tomorrow. |
I'm afraid Docker images on Circle are unable to take advantage of hardware acceleration. If I understand correctly, the Animated tests require hw accel. |
This is getting out of my depth but FWIW CircleCI 1.0 ran its tests in Docker too, which makes me think that it's possible to run the Animated tests somehow. Mind if I clone this PR and try to poke around? |
Yup, go for it. If you ssh into the machine, make sure to update your PATH in the same way as we do in https://github.com/facebook/react-native/pull/14955/files#diff-1d37e48f9ceff6d8030570cd36286a61R198 because $BASH_ENV points to a random file when this runs in the image. Once the ssh-enabled run has installed all deps, you should be able to use buck to run the tests manually. The JS bundle won't be available to you when you re-run with SSH enabled though, as it's built in a different job and the attach_workspace step fails when the build is retried. I'll see if I can provide the bundle as an artifact to aid with debugging. |
In case it helps, there's a difference in how we manage SDKs and the AVD in Circle 1.0 versus Circle 2.0. With Circle 1.0, we use the With Circle 2.0, I'm using Ideally, I'd set up the Android SDK and AVD in the same manner as we do in Circle 1.0, but it looks like both the android-23 and android-26 images are already set up with recent versions of the Android SDK where |
CircleCI doesn't let us map objects under /dev/shm from within the Docker container so another directory instead when running in CircleCI. This change shouldn't impact FB's internal CI.
See if we can get a green run on CircleCI 2 by commenting out tests that we know don't pass on CircleCI 1
@hramos I added a couple of commits at the end to fix Android unit tests (ended up being unrelated to GPU) and to comment out Android integration tests that were commented out in the CircleCI 1 config anyway. Tests look green now -- do you want to uncomment the Node 6 and Website jobs and then land this? |
Uncommented tests. This should be good to go now. |
@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification. |
Following the migration guide. Let's see what happens here.