LinearB On-Prem Agent v5.0.0

Released 2026-07-08.

The v5 major release. Analysis work no longer runs on a pool of background workers: every code, project-management, sensor and operational job is now a native Kubernetes Job, created and supervised by the agent itself. That change makes running work visible to ordinary cluster tooling, replaces the single global concurrency cap with a per-queue one, and adds priority and preemption. This release also adds supported OpenShift deployment, optional External Secrets Operator integration, and moves most service images onto a hardened base.

Upgrading from v4 requires configuration changes. Read Action required below and the v5 upgrade guide before you upgrade. At minimum, job pod sizing must be moved by hand — if you skip it, your job pods will run with no resource requests and no limits at all.

Action required

• Move job pod sizing to the scheduler. The scheduler-worker, scheduler-pm-worker and scheduler-sensors-worker subcharts no longer exist; delete any values you set under them. Set WORKER_REQUEST_CPU, WORKER_REQUEST_MEMORY, WORKER_LIMIT_CPU and WORKER_LIMIT_MEMORY through scheduler.image.env.plain instead. Do not skip this step even if you never tuned these values. Once the worker blocks are gone, the values fall back to a built-in "0" and job pods are created with zero requests and no limits: they become invisible to the agent's own capacity accounting and are classified BestEffort, which makes them the first thing the cluster evicts under node pressure. One set of values now covers every job type — if you previously sized project-management jobs differently from code jobs, choose values that suit the largest of them and contact LinearB support.
• Replace the concurrency keys. global.MAX_CONCURRENT_JOBS and global.OPS_RESERVED_SLOTS are gone. Concurrency is now set per queue with global.MAX_GIT_JOBS (default "5"), global.MAX_PM_JOBS (default "1") and global.MAX_SENSORS_JOBS (default "5"). The defaults match v4 behaviour for most installations. Operational jobs still bypass the limits, and there is no MAX_OPS_JOBS equivalent.
• Rename two keys. global.versions.pods_cleaner becomes global.versions.job_lifecycle_manager, and minio.DeploymentUpdate becomes minio.deploymentUpdate — the old spelling was silently ignored.
• If you run Datadog, the bundled Datadog chart moves from 3.110.10 to 3.170.1. Remove datadog-agent.datadog.kubeStateMetricsEnabled, datadog-agent.datadog.containerExcludeLogs and the whole kubeStateMetrics.image block. Kube-state metrics are now served by the Datadog Cluster Agent and the separate legacy deployment is gone — it had been querying Kubernetes API versions that no longer exist, producing a large volume of errors and no metrics for Ingress, PodDisruptionBudget, HorizontalPodAutoscaler, CronJob or CertificateSigningRequest resources. Note that datadog-agent.datadog.env is a list: overriding it replaces the chart's entries rather than merging with them.
• If your cluster already defines a PriorityClass named linearb-critical, linearb-high, linearb-medium or linearb-low with different values, reconcile it before upgrading. This release ships those four cluster-scoped PriorityClasses and Helm will fail on a value mismatch.
• If you deploy with Argo CD and ServerSideApply, set infra.minio.strategyMigrator.enabled: true for the upgrading release only, then turn it off again. MinIO moves from a rolling update to a recreate strategy, and ServerSideApply leaves the old rolling-update fields in place, which the Kubernetes API then rejects. A plain helm upgrade handles the transition on its own and needs nothing.

New features

• Native Kubernetes Jobs. Code, project-management, sensor and operational work now runs as batch/v1 Jobs rather than on Celery workers. Running work is visible to kubectl and to any cluster tooling you already use, and the pods carry the agent's own labels
• Job Lifecycle Manager, a new component that replaces pods-cleaner. It watches job events, reports completion back to LinearB, re-queues work that was preempted or lost with a node, and cleans up finished pods
• Priority and preemption. Jobs are scheduled under four priority classes; operational jobs run at the highest priority and can preempt other work to get on the cluster
• Per-queue concurrency, so code, project-management and sensor throughput can be tuned independently of each other
• OpenShift support. Every image now runs under the restricted-v2 security context constraint with an arbitrary UID, the chart renders OpenShift-specific security contexts and an OpenShift Route for the webhook receiver under global.K8S_PLATFORM: openshift, and an Argo CD application manifest and reference values files are provided
• External Secrets Operator support. The chart secret, the image-pull secret and the custom root CA can each be sourced from a ClusterSecretStore instead of from Helm values. Set global.infra.commonSecret.mode to externalSecret to sync from a secret store, or to existing to use a Secret you created yourself. The default, helm, is unchanged from v4 and does not require the operator
• Job pod placement. global.workerPods pins job pods to specific nodes with a node selector or affinity rules
• New v5 upgrade guide, covering every configuration change between v4 and v5

Bug fixes

• gitStream services trust custom root certificates. The gitStream services run on Node, which reads none of the three certificate variables the agent was setting, so outbound HTTPS to a self-hosted SCM failed with a certificate error that surfaced as the misleading message "Gitstream is not installed properly"
• The forward proxy reaches the tunnel again when global.EXTERNAL_PROXY is enabled. The destination it dialled did not match the name the tunnel Service actually renders under
• Job pods get the scratch directories they need — /tmp, and the per-job-type working directories — directly from the agent. Jobs could previously fail at startup with a permission error on a directory they could not create
• minio.deploymentUpdate is read correctly; under its previous PascalCase spelling the setting had no effect at all
• Wrapper images no longer destroy /home/linearb from the underlying LinearB image, which had left the project-management collector unable to find its own startup script
• The ingress migration examples in the usage-scenarios guide put installController and className under the wrong key; they now show global.ingress, which is what the chart reads. The guide also gains a troubleshooting entry for the certificate error seen when upgrading the ingress admission webhook

Improvements

• Pull-request security scan results from Orca and SonarQube are collected and reported as a metric
• Jira Cloud change history is collected through the bulk endpoint, which is substantially faster on large projects, with a per-issue cap so a very long history cannot dominate a run
• Sensors iterate every Bitbucket workspace when discovering repositories, rather than only the first
• Cursor daily usage is requested in windows of at most 30 days, so long backfills complete
• Bot contributor identifiers are cached, reducing repeated lookups during collection
• Project-management custom-field settings are read within the scope of the sensor that owns them

Security and dependency updates

• The scheduler, job-lifecycle-manager, agent-poller, agent-cli, jobs-suite-worker, jobs-suite-dispatcher and opa-diagnostics images now build on a hardened LinearB base, and the forward proxy on a hardened NGINX mirror, reducing the vulnerability surface. agent-api and webhook-receiver still build on their upstream public bases in this release; they are addressed in v5.0.2
• gitStream: the public troubleshooting analytics endpoint is disabled and its internal-request authentication bypass removed; the playground endpoint now requires a verified token and derives the organization from it; secrets and raw git errors are no longer written to logs

Known issues, fixed in v5.0.2

• Running behind a corporate proxy in transparent mode does not work in this release: the agent presents an internal cluster name during the TLS handshake rather than the real API hostname. connect mode works where the proxy tolerates the mismatch. Fixed in v5.0.2, with no configuration change needed
• The v5 upgrade guide published with this release gives the wrong key in two places. Worker sizing was documented under global.workerPods, which only controls pod placement — see Action required above for the keys that actually apply. Disabling the bundled NGINX ingress controller was documented as ingress.installController, which the chart does not read; the correct key is global.ingress.installController. Both are corrected in the v5.0.2 guides

Component versions