Skip to content

Latest commit

 

History

History
212 lines (150 loc) · 12 KB

README.md

File metadata and controls

212 lines (150 loc) · 12 KB
Raw

Build Guide

Quickstart

  1. Clone the repository

  2. Install the dependencies

     npm install

  3. Build the project

    npm run build

  4. Start the server

    npm start

  5. Navigate to : http://localhost:8080/

Get the Code

  • Setup Git if it isn't already (link).
    • New to git or need a refresher? Now's a good time to learn! Easy tutorials here.
    • Make sure your SSH keys are configured (linux | mac | windows).
    • Double-check your settings for name and email: git config --get-regexp user.*.
    • Recommended Git settings:
      • git config --global fetch.prune true - when fetching remote changes, remove any remote branches that no longer exist on the remote.
  • Have commit access to CesiumJS?
    • No
      • Fork cesium.
      • Use the GitHub website to delete all branches in your fork except main.
      • Clone your fork, e.g., git clone [email protected]:yourusername/cesium.git.
      • Make changes in a branch, e.g., git checkout -b my-feature.
    • Yes
      • Clone the cesium repo, e.g., git clone [email protected]:CesiumGS/cesium.git
      • Make changes in a branch, e.g., git checkout -b my-feature.

Build the Code

Prerequisites:

  • Install Node.js on your system. Building Cesium requires Node 18.x or newer.

Cesium uses npm modules for development, so after syncing, you need to run npm install from the Cesium root directory:

npm install

Cesium ships with a simple HTTP server for testing. Once all modules have been installed, run npm run build to build the project:

npm run build

Then, run the development server:

npm start

Then browse to http://localhost:8080/. The landing page includes apps and tools commonly used during development, including:

Development Server

By default, the server only allows connections from your local machine. To allow connections from other machines, pass the --public option to npm. Note the extra -- is intentional and required by npm.

npm start -- --public

The development server has a few other options as well, which you can see by passing the --help parameter:

npm start -- --help

Build Output

Cesium offers a few different distributions. When developing, make sure to pick the one that fits your app's architecture.

  • IIFE (immediately-invoked function expression) - A pre-processed bundle, optimized for the browser, and with web worker code inlined. It defines a Cesium global variable upon loading Build/Cesium/Cesium.js. This is what is available via the CDN. While much of our documentation uses IIFE-style globals for ease-of-use, we do not recommend this approach for production apps.
  • ESM (ECMAScript modules) - Standard for packaging JS code which is supported by most browsers and NodeJS. Modules use import and export statements. Unprocessed, individual modules are available in the Source directory, accessible by importing Source/Cesium.js; A single pre-processed bundle by importing Build/Cesium/index.js.
  • CJS (CommonJS) - A pre-processed, bundled module packaged for running in NodeJS accessible by requiring index.cjs.

In much of our documentation, we use IIFE as it can be easily loaded with a CDN and defines a global Cesium variable with all modules attached.

For a production app, we recommend using the Source modules directly which will allow your build tool of choice to reduce the final release's size using tree shaking.

Read the complete list of build scripts and options below for more details.

While you can use the editor of your choice to develop Cesium, certain files, such as glsl and new tests, require that the build task be executed in order for the changes to take effect. You can use the build-watch script to have this happen automatically.

Build Scripts

Cesium uses gulp for build tasks, but they are all abstracted away by npm run scripts.

Specify the target(s) at the command line:

npm run [target-name]

Here's the full set of scripts and what they do.

  • Build scripts -- build and package the source code and documentation
    • build - A fast, developer-oriented build that bundles the source modules to produce all-in-one files in the Build/CesiumUnminified directory that exposes the entire Cesium API attached to a single global Cesium object. Run this when a GLSL shader is changed since the .glsl file is converted to a .js file with a string for the GLSL source.
      • --minify - Minifies the output for optimized loading. Specifying this option will output to Build/Cesium.
      • --removePragmas - Optimizes the output by removing debugging code that validates function input and throws DeveloperErrors. The removed sections are marked with //>>includeStart('debug', pragmas.debug); blocks in the code.
      • --node - Bundles an index.cjs module targeted for use in NodeJS
    • build-watch - A never-ending task that watches your file system for changes to Cesium and builds the source code as needed. All build options are also available for this task.
    • build-apps - Builds the example applications (such as Cesium Viewer) to produce self-contained, minified, deployable versions in the Build directory.
    • build-docs - Generates HTML documentation in Build/Documentation using JSDoc 3. See the Documentation Guide for more details.
    • build-ts - Generates a TypeScript definitions file for the Cesium library
    • build-third-party - Generates ThirdParty.json, a file which lists the latest licensing information of installed third party modules
    • release - A full release build that creates a shippable product, including generating documentation.
    • make-zip - Builds a zip file containing all release files. This includes the source ESM modules, bundled ESM and IIFE format Cesium.js, plus the bundled minified versions of ESM and IIFE, the generated documentation, the test suite, and the example applications (in both built and source form).
  • Utility scripts -- code coverage, static code analysis, and other utilities
    • clean - Removes all generated build artifacts
    • cloc - Runs CLOC to count the lines of code on the Source and Specs directories. This requires Perl to execute.
    • coverage - Runs coverage and opens the default browser with the results
    • eslint - Runs ESLint, a static code analysis tool, on the entire source tree
    • prettier - Formats the code base using Prettier
    • prettier-check - Verifies prettier formatting, but does not write the output
  • Testing scripts -- build and run the unit tests
    • test - Runs all tests with Karma using the default browser specified in the Karma config file.
    • test-all - Runs all tests with Karma using all browsers installed on the current system
    • test-non-webgl - Runs only non-WebGL tests
    • test-webgl - Runs only WebGL tests
    • test-webgl-stub - Runs all tests using the WebGL stub, which WebGL calls a noop and ignores related test expectations
    • test-webgl-validation - Runs all tests with Karma and enables low-level WebGL validation
    • test-release - Runs all tests on the minified release version of built Cesium
  • Deployment scripts
    • deploy-status - Sets the deployment statuses in GitHub, for use in CI
    • deploy-set-version - Sets the version of package.json, for use in CI

Continuous Integration

Cesium uses GitHub Actions for continuous integration. Reusable actions are defined in /.github/actions/ and workflows in .github/workflows/.

(Although outdated, the blog post Cesium Continuous Integration contains background on the CesiumJS CI process.)

A workflow is triggered whenever someone pushes code to the Cesium repository, or an external contributor opens a pull request. After the build has completed, at the bottom of the pull request page the status of the build is shown. In the dropdown menu, individual checks are displayed. Logs and deployed artifacts can be accessed by clicking the "Details" link.

GitHub Action Checks

The build of any branch of CesiumJS can be accessed under the Branches page, and clicking the icon next to the branch name.

GitHub Branches

Additional set up is required for deployment if you do not have commit access to Cesium.

Configure a Different S3 Bucket

It is possible to configure your development branch of CesiumJS to deploy build artifacts to a different AWS S3 Bucket. If you are using the cesium-public-builds bucket and have valid credentials, skip to Configure S3 Credentials

  • In .gtihub/workflows/dev.yml, in the following lines, replace "cesium-public-builds" with the name of your S3 bucket.
aws s3 sync ./Build/Coverage s3://cesium-public-builds/cesium/$BRANCH/Build/Coverage --delete --color on
aws s3 sync Build/unzipped/ s3://cesium-public-builds/cesium/$BRANCH/Build/ --cache-control "no-cache" --delete
  • In gulpfile.js, edit the following line:
const devDeployUrl = "https://ci-builds.cesium.com/cesium/";
  • Edit the URL to match the URL hosting the S3 bucket specified in the previous step.

Configure S3 Credentials

To configure CI for deployment for a fork of Cesium, you must have valid credentials to an S3 bucket.

  • Go to your fork of Cesium
  • Click the Setting tab
  • In the left sidebar, under the Security section, click Secrets and Variables > Actions
  • Under Repository secrets add two environment variables, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, with your access key and secret key

GitHub Environment Variables