Skip to content

Protect Builds

Start protection before build work and run cleanup after success, failure, or normal cancellation. Choose the commands for your execution model:

Choose an Execution Model

Execution modelSensor placementStartCleanup
Persistent runnerHost serviceendura job startendura job stop
Ephemeral hosted VMStarted by workflowendura job startendura sensor stop
Ephemeral build containerInside build containerendura job startStop job, then Sensor before container exit
Container using host SensorHost; CLI and socket in containerendura job startendura job stop with the same socket and workspace
Kubernetes build PodNode DaemonSet; CLI and node socket in Podendura job startendura job stop before container exit

Use labels, tags, capabilities, or node selectors to place builds on supported Linux x86-64 hosts with a ready Sensor. Each provider guide includes runnable configuration.

Prepare Managed Discovery

Create the provider integration with a read-only credential, enable its pipeline and build synchronization jobs, and confirm the pipeline exists before instrumenting builds. The provider guide supplies permissions, schedules, and mapping.

Start Protection Before Build Work

Start before project-controlled commands, including checkout when the provider supports it in the same execution context. Capture and log the returned job ID.

For fallback enforcement before checkout, provision a reviewed policy outside the repository and pass its absolute --policy path. The default lookup uses the CLI’s current directory, independently of --workspace; a repository file can be missing or stale. A matched Team Server policy overrides it. See policy selection.

Clean Up Every Outcome

Use the provider’s unconditional cleanup mechanism. Runner loss, forced termination, source-preparation failures, and exhausted timeouts can still prevent cleanup.

A persistent Sensor needs job cleanup. Stopping an ephemeral Sensor also stops its jobs, prints derived policies, and attempts telemetry delivery. A failed submission is not replayed. Container cleanup must run while the Sensor and workspace remain reachable; some providers use a separate cleanup shell or container.

Preserve an existing build failure and fail otherwise successful work if cleanup fails. Keep startup errors visible. Do not suppress normal integration errors with ENDURA_EXIT_ZERO or --exit-zero.

Handle Canceled Builds

For recognized CI/CD builds, an authorized SIGINT, SIGTERM, or SIGKILL from outside every protected job marks cancellation. The Sensor permits that signal and retains other policy controls.

ENDURA_JOB_CANCELLATION_TIMEOUT retires the canceled job after 15 minutes by default. Setting 0 disables retirement, not provider cancellation. Use 0 only with reliable explicit cleanup. Workload jobs do not receive this exception.

Keep provider cleanup: retirement is a fallback when a persistent Sensor survives missed cleanup.

Secure Ephemeral Runners

When a job starts its own Sensor:

  1. Keep the Team Server URL in nonsecret configuration. Across sudo, preserve only required named variables.
  2. Expose license and Sensor token only during startup where supported; otherwise remove them before project-controlled work.
  3. Start as root, with ENDURA_LOG_FILE in a retainable location.
  4. Check unprivileged endura sensor status and root-only endura sensor hooks.
  5. Stop the Sensor unconditionally and retain its log after success or failure.

Graceful shutdown makes ENDURA_BATCHER_AUTOFLUSH unnecessary solely for an ephemeral runner.

Verify the Protected Build

Run checkout, build, and cleanup. Confirm Sensor connectivity and hook coverage, the managed run under Pipelines > Builds, and expected policy output with no active job left behind.