[Feature] ViroCore - ViroReact Continuous Integration investigation

[dthian]

This issue is filed to track an investigation into a CI approach to see if that is possible on the render side of things. Pros:

• Helps us catch build breaks with bad pull requests earlier and quicker.
• Provide the community with built renderers with the latest features to easily experiment with without doing a full render build.
• Enables ViroReact devs with much easier & rapid development for users that want to propagate features from the renderer into Viro React.

Ideally, for the renderer ViroCore CI: Building will produce a viroreact-release.aar for Android and ios/dist for iOS.

Ideally for the Viro Bridge CI: It will somehow consume the built renderer, grab all the dependencies, and spit out a react-viro-*.tgz file.

I'll update my findings as i go along here.

[Hless]

Good one. Willing to participate on this one. Personally I would like to see virocore and viroreact in the same repo, perhaps using 'lerna' or yarn workspaces. That would make it possible to keep virocore and viroreact in one working state or version, since these projects are so heavily dependent on each other. It also makes it possible to boostrap the environment for people who just want to work on Viro React (so you would run a single command in the root of the repo to build viro core & react and run it).

Edit: Another benefit is that you can move the testbed app into it's own directory/package, keeping the inter-package dependencies even cleaner

[dthian]

Personally I would like to see virocore and viroreact in the same repo

Currently, ViroCore contains the renderer + Android Java APIs, while ViroReact contains react-native specific APIs. Although dependent, they are two separate products and thus can also have independent features and commits. Thus, it's probably best to keep them separate (You can still build them together locally, having a "single command" is a nice to have). More importantly, I think that it helps:

• Keep a clean separation of native c++ render-specific implementations vs React-Native bridge implementations. This allows for better compartmentalization of components, building and testing, and as well as better tracking of commits and bugs at the renderer level -> bridge level.

• Enable developers to constantly build render features and / or Java APIs without involving the bridge at all. Likewise for developers who just wants to make bridge modifications (they don't have to know about the renderer). This scales more appropriately as we have different kinds of bridges, rather than having one super bloated repo.

Having said the above, i do agree that keeping ViroCore and ViroReact in sync / one working state or version. I'm not sure what the solution to this is yet, will have to think about it some more. This should be alright for now, as it is all handled / enforced by administrators and thus is transparent to the community.

Another benefit is that you can move the testbed app into it's own directory/package, keeping the inter-package dependencies even cleaner

The testbed app is currently within it's own repo. But feel free to talk to @VikAdvani about moving it into it's own directory within the Viro repo.

[dthian]

Marking as completed and closing: I’ve implemented CI pipelines for both ViroCore and ViroReact. Both CI pipeline statuses can be seen on it’s corresponding ReadMe pages.

To see the current status of CI builds, simply click on the actions tab within the github project. As shown below: For the ViroCore repo, users can simply use the CI built renderer For the ViroReact repo, user can simply re-install the new .tgz The readme has also been updated with instructions on how to use the CI-built artifacts.

This should help reduce iteration deployment friction when building with or modifying Viro. Having CI build workflows pros:

• Help us catch a bad commits that results in compile errors very early in the pipeline.
• Enable developers to quickly determine if their PR will break the build (due to workflow status checks).
• Enable developers to download the latest mainline build (To use the latest features / fixes that are not yet released - they don’t have to re-build the whole framework.)

As always, feel free to reach out to me directly if you have any questions / concerns.