Environment variables & files

Provide additional build configuration for your project

Nevercode extends build configuration options by using a variety of variables and uploading relevant environment files and/or custom build scripts. Nevercode exports several read-only environment variables (which you can reference below) but also enables you to define your own custom variables.

This guide covers:

Overview of environment variables and files

Environment variables enable you to configure relevant variables for your builds. On Nevercode, these variables are categorized as follows:

  • Environment variables: exported as read-only by Nevercode during the build and are not visible in the UI. Environment variables are used in build scripts and contain information about the build machine, the current build, etc. See the list of environment variables here.
  • Custom environment variables: defined by you; custom variables will always override Nevercode defaults. Custom environment variables are useful for storing information that you do not want to store in the repo, such as your credentials or workflow-specific data.
  • Magic variables: defined by you to fine-tune various aspects of your project(s). These are a set of Nevercode-specific variables that you can use to customize build behavior and some default settings. Read more about magic variables here.

Environment files are relevant files and scripts you can upload that should be used or be accessible in your project during the build.

  • Environment files: upload files that are not in your repository but should be available to your build scripts.
  • Custom build scripts: upload custom build scripts for specific build steps that you want to be run during the build process. Read more about custom build scripts and steps here.

Defining environment variables

To define environment variables:

  1. Navigate to the Environment page in your project settings.
  2. Type the variable name and the corresponding value to the fields.

Adding a custom variable

  1. Select Hidden if you wish to hide the value of the variable in Nevercode UI.
  2. Click Add variable to save the variable.

Alternatively, you can add several environment variables at once by uploading a text file. For that, click upload variables from the text file. Each variable must begin on a new row and have a name and a value, delimited by an equals sign. For example:


To edit the variable name or value:

  1. Click the field of the value and enter a new one.
  2. Press Enter to save or click the Save icon on the right.

To delete a variable, click the Delete icon on the right.

Adding custom environment files

Custom environment files are files that are not present in your source repository for your projects but that should be accessible from your build script.

To upload an environment file:

  1. Navigate to the Environment page in your project settings.
  2. In the Environment Files section, drag and drop your file to the upload area or click on it to browse and select from your file directory.
  3. Type the name of your file. Note that the entered name will be treated as environment variable and its value is the path to the uploaded file during the build.
  4. Click Save.

Adding a custom environment file

Example use case for custom environment files

For example, your build relies on a configuration file configs/config.json, but you'd like to have a different configuration for CI builds. Let's assume you've uploaded the desired configuration file ci_config.json as environment file and named it CI_CONFIG_JSON. Now, you could swap the original file for Nevercode builds in your repository with a simple post-clone script (read more about custom build steps here) as follows:


mv $CI_CONFIG_JSON $NEVERCODE_BUILD_DIR/configs/config.json

where $NEVERCODE_BUILD_DIR points to the cloned repository path in Nevercode virtual machines.

Nevercode read-only environment variables

By default, Nevercode exports the following environment variables during all builds:




Path to Android SDK


Path to Android NDK


Number of the build for this project in Nevercode








The current branch being built, for pull requests it is the destination branch




Number of the build for this project in Nevercode


Absolute path to the cloned repository in Nevercode builders


Config for Cordova (release or debug) and iOS (Release or Debug). Empty string for Android


Contains all of the artefact files that will be included in the final artefacts zip file


Name of the project to be built. For iOS it is project.xcodeproj or project.xcworkspace, for Android it is the name of the Gradle subproject (like app) and empty string for Cordova/Ionic


Task for Android, Scheme or Target for iOS


UUID of the build


Build step status as success, failure or skipped.


Build's web URL


Performs a full clone of the repository instead of top 50 commits


Commit hash that is currently being built by Nevercode, for pull request builds it is hash of the source commit


All of the files included in this directory will be added to the artefacts zip file


true, if the current build is building a feature branch, false otherwise


UUID of the pull request for the Git provider (Bitbucket, Github etc)


Platform of the project that is being built, value is one of android, cordova, ionic, ios, react_native


UUID of the project that is being built


The slug of the repository that is currently being built in the form owner_name/repository_name


Get test step status success or failure


true, if the current build is building a pull request, false otherwise


Name of the pull request's destination branch


Name of the pull request's source branch


The slug of the PR source repository that is currently being built for PR builds, empty otherwise (owner_name/repository_name)


Integer ID of the pull request for the Git provider (Bitbucket, Github etc)


Directory for custom test results


Path to Java 7


Path to Java 8


Path to default Java, version 8 by default


Path to Android NDK

Updated about a year ago

Environment variables & files

Provide additional build configuration for your project

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.