https://github.com/nativescript/nativescript-remote-builds
A NativeScript plugin for remote builds when running and publishing NativeScript apps without env setup.
https://github.com/nativescript/nativescript-remote-builds
Last synced: about 1 month ago
JSON representation
A NativeScript plugin for remote builds when running and publishing NativeScript apps without env setup.
- Host: GitHub
- URL: https://github.com/nativescript/nativescript-remote-builds
- Owner: NativeScript
- License: apache-2.0
- Created: 2020-01-13T08:11:13.000Z (almost 6 years ago)
- Default Branch: master
- Last Pushed: 2022-04-15T18:18:11.000Z (over 3 years ago)
- Last Synced: 2024-10-29T15:51:54.853Z (about 1 year ago)
- Language: JavaScript
- Homepage:
- Size: 1.6 MB
- Stars: 26
- Watchers: 22
- Forks: 9
- Open Issues: 13
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# nativescript-remote-builds
[](https://travis-ci.com/NativeScript/nativescript-remote-builds)
Have you ever been wondering how to:
* build **NativeScript apps for iOS on Windows or Linux**?
* setup a **stable CI** for your NativeScript apps?
* avoid the **iOS code signing management**?
If so, the **NativeScript Remote Plugins** is just for you! :rocket:
## How does it work?
The plugin is using several **NativeScript CLI hooks** and modifying its behavior by:
* **Skipping** the local **[native tooling[1]](#tooling) requirements**.
* **Skipping the native resources** handling during the CLI **prepare phase** - they will be handled in the remote.
* **Replacing the CLI local build** with the build method of the selected remote.
The **rest of the CLI logic is working as usual**, for example, the *tns debug* command is preparing the JavaScript, uploading it to the connected devices, showing logs, opening debug sockets, showing an URL for debugging and so on.
## How does it differ from the NaticeScript CLI Cloud extension?
Comparing the cloud builds part of the [NativeScript Cloud extension](https://github.com/NativeScript/nativescript-cloud) and the [NativeScript Remote Builds plugin](https://github.com/NativeScript/nativescript-remote-builds), they look similar.
The main differences come from the fact that **the NativeScript Remote Builds plugin enables the existing NativeScript CLI commands on environments without any [native tooling[1]](#tooling) requirements** instead of providing additional commands like the `tns cloud` ones. The Remote Builds plugin is also **designed to be stable and reliable in a CI environement**.
Here's a comparison table between the NativeScript Cloud Extension and the NativeScript Remote Builds plugin:
| | Cloud Extension | Remote Builds Plugin |
| :--- | :---: | :---: |
| Build, Run and Publish without [native tooling[1]](#tooling)|  |  |
| Debug without [native tooling[1]](#tooling) | [[2]](#cloudDebug)|  |
| Run Unit Tests without [native tooling[1]](#tooling) |  |  |
| [Automatic iOS Signing Management[3]](#signing) |  |  |
| [Full CI Support[4]](#ci) |  |  |
| [Full Environment Information[5]](#envInfo) |  |  |
| [Full Environment Control[6]](#envControl) |  |  |
| Just the default NativeScript CLI commands |  |  |
| Free | [[7]](#cloudPrice)| [[8]](#pluginPrice)|
> *The comparison is based on the CircleCI remote of the NativeScript Remote Builds Plugin*
- native tooling[1]
- Any native environment requirements like Java, Android SDK, Android Studio, macOS, Xcode, Cocoapods, Docker and so on.
- cloud extension debug support[2]
- It is available only through NativeScript Sidekick.
- iOS signing management[3]
- If the end-user is responsible for passing the `--provision` flag and picking the proper certificate based on the current build configuration. In the Remote Builds plugin, this is handled out of the box by the Fastlane Match service.
- full CI support[4]
- If the user can build and run tests on pull requests or commits. In other words, if it is supported to build multiple versions of the same app in parallel.
- full environment information[5]
- If the full environment information is available to the users (e.g. the versions of the OS and the native tooling[1].
- full environment control[6]
- If the environment setup can be controlled by the user (e.g. change the versions of the os and the native tooling[1].
- cloud extension price[7]
- The NativeScript Cloud extensions is providing a limited number of free builds.
- remote builds plugin price[8]
- The Circle CI provider of the NativeScript Remote Builds plugin is just depending on the Circle CI pricing. It provides a limited number of free Android Builds for everyone and a limited number of free iOS builds for open-source projects.
## Installation
It's just a regular NativeScript plugin and could be installed from npm:
1) `cd {{yourNativeScriptAppRoot}}`
2) `npm i nativescript-remote-builds`
In addition, as the plugin is written in JavaScript, it allows a direct GitHub installation:
1) `cd {{yourNativeScriptAppRoot}}`
2) `npm i https://github.com/NativeScript/nativescript-remote-builds/tarball/master`
> IMPORTANT: The plugin depends on NativeScript CLI hooks even before the CLI installs the node packages. If you delete your `node_modules` folder, ensure that `npm i` is called before the `tns` commands, otherwise you could get unexpected exceptions.
## Setup
The plugin supports two configuration files expected in your **NativeScript app root directory**:
* `.nsremote.config.json` - the main plugin config where you have to select a `remote`, follow the [remote setup section](#remote-setup) for further details.
* `.nsremote.env.json` - an **optional file** allowing you to override the local and remote **environment variables**, most of them contain **sensitive** information and it's highly recommended to **ignore it from your source control**.
> NOTE: Both of the files are used only locally and replaced with an empty file when the plugin sends your app to the remote.
## Remote Setup
* [Circle CI Setup](docs/CIRCLECI.md)
## Usage
Just use the NativeScript CLI commands as usual. The plugin hooks to the NativeScript CLI build process and replaces it with remote builds. In addition, the `tns publish android` command is now working and publishing the app from the remote.
## Local Builds
You can always use your local machine instead of the remote builds by providing the `--env.local` argument to your CLI commands. For example:
`$ tns run android --env.local`