C3 AI Documentation Home

Optimize Build Times in C3 AI Release Management

Build times in large repositories often grow gradually as packages, tests, and UI code accumulate. Optimizing build performance requires more than tuning individual settings. You must also identify the build's critical path and apply changes in the right order.

This tutorial shows developers how to reduce build times in C3 AI Release Management.

Before you begin

See the following pages for necessary prerequisite knowledge:

Step 1: Identify the build bottleneck

Before you make changes, identify where in the build path the build takes a long time.

Optimizing steps outside the build's critical path does not reduce total build time. Instead, find the longest-running sequence of steps that determines overall build duration.

Look for:

  • Total build duration trends across recent builds.
  • Which pipeline step runs the longest.
  • Whether a step is retried (especially UI bundling).
  • Whether tests or UI bundling dominate the critical path.

Where to do this

Use the build and pipeline views in C3 AI Studio to inspect build duration and pipeline execution details, see also the Monitor Application Builds Across Branches in C3 AI Release Management tutorial.

If UI bundling or test execution dominates the build time, continue to the next steps. Otherwise, focus only on the step that appears on the critical path.

Step 2: Reduce unnecessary work

Always reduce the amount of work the build performs before attempting parallelization or hardware tuning. This step typically provides the fastest and safest improvements.

Limit which packages are built and tested

In large repositories, builds typically generate artifacts and run tests for packages that are not relevant to a given branch or workflow.

Use build configurations to:

  • Include only specific packages.
  • Exclude packages that do not need to be built or tested.

Build configurations suit feature branches and PR workflows that make targeted changes in specific packages.

To configure package inclusion or exclusion, see Create and View Build Configurations for C3 AI Release Management

Disable builds and tests for non-essential branches

If certain branches do not require continuous builds, disable them to significantly reduce overall build load and queue contention.

You might want to disable builds for:

  • Archived branches.
  • Experimental branches.
  • Branches used only for documentation or analysis.

To enable or disable builds for a branch, see:

Step 3: Optimize UI bundling

UI bundling is frequently the longest-running step in the build pipeline and a common source of retries.

If UI bundling appears on the critical path, apply these optimizations in order.

Skip unnecessary UI bundles by branch type

For PR and feature branches, development (DEV) UI bundles are typically sufficient to support UI tests. Production (PROD) bundles are usually only required for mainline builds that produce deployable artifacts.

Skipping PROD bundles on PR branches can significantly reduce UI bundling time.

Branch group configuration determines UI bundle generation behavior.

To configure UI bundling behavior, see Customize UI Bundling Configurations for C3 AI Release Management

Bundle only packages that contain UI code

By default, any package that depends on a UI package may undergo UI bundling, even if it contains no UI code itself.

In large repositories, this often results in unnecessary bundling of documentation-only or dependency-only packages.

You can restrict UI bundling to a specific list of packages by:

  • Defining UI package lists in build configuration.
  • Customizing the generateUiBundles step in the build pipeline.

To implement this optimization, see:

Eliminate UI bundling retries

Repeated UI bundling retries can multiply build duration and make completion times unpredictable.

Optimizing this step is often a tradeoff between hardware costs and build times. For this reason, you must communicate to a C3 AI OPS expert to reconfigure or customize your nodepool configuration.

Common causes include:

  • Insufficient memory.
  • Node eviction of long-running bundling steps.
  • Inappropriate hardware profiles.

To address this:

  • Increase memory for the UI bundling step.
  • In your node pool configuration, set the hardwareAvailability flag to high to use on-demand nodes instead of spot instances.
  • Prevent eviction for the bundling executor by ensuring your nodepool configuration sets the doNotEvict flag to true.

For detailed instructions, see:

Step 4: Optimize test execution

If tests dominate the critical path, apply the following optimizations.

Parallelize tests intentionally

By default, tests for a package may run serially or in unbalanced groups.

You can reduce test duration by defining test strategies that:

  • Group tests by runtime type (for example, UI browser tests vs. backend tests).
  • Balance execution time across test groups.
  • Avoid placing all slow tests in a single group.

Test strategies are configured through build configurations.

For more information on test strategies, see Create and View Build Configurations for C3 AI Release Management.

Avoid duplicate Python test execution

Python tests can execute multiple times when similar tests exist in more than one runtime-specific test path (for example, both client-side and server-side Python runtimes).

In many repositories, it is sufficient to execute Python tests only in the server-side runtime. When you consolidate Python tests into a single server-side test path, you avoid duplicate execution and reduce total test time. To do this, reorganize test files rather than change build configuration. For example:

Before (mixed / duplicated runtimes)

Text
myPackage/test/py-data-science/test_myTest1.py
myPackage/test/py-data-science-server-py4j-test/test_myTest2.py

After (single server-side runtime)

Text
myPackage/test/py-data-science-server/test_combinedTest.py

Keep the tests within an existing package where possible. This change consolidates Python test execution into one server-side runtime, and allows tests to run once and in parallel with UI bundling without introducing additional C3 packages.

Decouple backend tests from UI bundling

If packages have both backend tests and also contain UI code, the tests may be blocked until UI bundling completes.

Moving backend tests into backend-only packages allows them to run in parallel with UI bundling instead of waiting for it to finish.

This change often provides substantial reductions in critical-path time but may require codebase refactoring.

Step 5: Tune pipeline and system-level limits (advanced)

After you reduce scope and optimize pipeline behavior, you may still encounter limits imposed by executor availability, timeouts, or system-wide resource caps.

Consult your administrator to adjust these settings. These settings control shared executors, timeouts, and resource allocation, and changes can affect other builds.

Adjustment examples include:

  • Increase executor concurrency.
  • Adjust executor startup or idle timeouts.
  • Increase stash limits.
  • Adjust build-level timeouts.

For more information, see:

Next steps

After applying optimizations, continue to monitor build duration trends and pipeline behavior. Build performance evolves over time as repositories grow, and C3 AI recommends periodic reassessment.

Use this guide as a repeatable process whenever build times begin to increase.

Was this page helpful?