v2.36.8 Armory Continuous Deployment Release (Spinnaker™ v1.36.1)

Release notes for Armory Continuous Deployment v2.36.8.

2026-03-05 release notes

Note: If you experience production issues after upgrading Armory Continuous Deployment, roll back to a previous working version and report issues to http://go.armory.io/support.

Required Armory Operator version

To install, upgrade, or configure Armory CD 2.36.8, use Armory Operator 1.8.6 or later.

Security

Armory scans the codebase as we develop and release software. Contact your Armory account representative for information about CVE scans for this release.

Breaking changes

The following configuration properties have been restructured:

Previous Configuration:

tasks:
  days-of-execution-history:
  number-of-old-pipeline-executions-to-include:

New configuration format

tasks:
  controller:
    days-of-execution-history:
    number-of-old-pipeline-executions-to-include:
    optimize-execution-retrieval: <boolean>
    max-execution-retrieval-threads:
    max-number-of-pipeline-executions-to-process:
    execution-retrieval-timeout-seconds:

These changes improve query performance and execution retrieval efficiency, particularly for large-scale pipeline applications.

Performance Improvements for SQL Backend

Known issues

Echo Filter enabled pipelines feature

Spinnaker OSS Version 1.31.0 introduced a feature to filter pipelines from front50, that was disabled by default. Version 1.35.0 enabled it by default, which is not recommended and can cause issues with automated triggers. In Armory CD 2.36.2 we recommend to explicitly disable this feature by setting the following configuration:

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      echo:
        pipelineCache:
          filterFront50Pipelines: false

Highlighted updates

Clouddriver: Redis scheduler configuration validation

Clouddriver now validates Redis scheduler configuration keys more strictly at startup:

  • Legacy scalar redis.scheduler is rejected.
  • Legacy redis.parallelism is rejected.
  • Use nested keys under redis.scheduler.*.

Before:

redis:
  scheduler: default
  parallelism: -1

After:

redis:
  scheduler:
    enabled: true
    type: default
    parallelism: -1

If redis.scheduler.type is missing or blank, Clouddriver defaults to default for compatibility.

Security hardening: URL restriction validation for artifacts and webhooks

This release tightens URL host validation for artifact accounts and Orca webhook URL restrictions:

  • Validation now uses parsed host handling (HttpUrl.host()) instead of authority fallback parsing.
  • This prevents authority/userinfo patterns from bypassing hostname checks.
  • URL handling for underscore hostnames and IPv6 input is stricter and more predictable.

If you use uncommon URL formats (for example userinfo segments, unbracketed IPv6 literals, or underscore-based hosts), test those paths after upgrade.

Clouddriver SQL cache: sharding-aware unknown-agent cleanup

SqlUnknownAgentCleanupAgent now respects shard ownership and includes additional safety controls to avoid cross-pod or startup-race cleanup behavior in SQL cache environments.

Key updates:

  • The cleanup agent remains opt-in and disabled by default.
  • The cleanup agent is only created when sql.read-only=false.
  • Cleanup skips when sharding state is uninitialized or misconfigured.
  • New controls include minRecordAgeSeconds, dryRun, and excludedDataTypes.

Configuration:

sql:
  unknown-agent-cleanup-agent:
    enabled: false
    pollIntervalSeconds: 120
    timeoutSeconds: 60
    minRecordAgeSeconds: 300
    deleteBatchSize: 100
    dryRun: false
    excludedDataTypes: []

HA deployment guidance

In HA mode, enable sql.unknown-agent-cleanup-agent.enabled: true only on Clouddriver caching pods.

For caching pods:

sql:
  unknown-agent-cleanup-agent:
    enabled: true

For all non-caching Clouddriver pods:

sql:
  unknown-agent-cleanup-agent:
    enabled: false

Clouddriver cache sharding: pluggable strategy and key extraction

Cache sharding now supports pluggable strategies and key extractors for Redis and SQL sharding observers:

  • strategy: modulo (default, preserves legacy ownership mapping)
  • strategy: canonical-modulo (canonical positive modulo)
  • strategy: jump (jump consistent hash, less key movement during scale events)
  • sharding-key: account | region | agent

Defaults remain strategy: modulo and sharding-key: account, so existing behavior is preserved unless you opt in to a different strategy/key.

Configuration:

cache-sharding:
  strategy: modulo
  sharding-key: account
  replica-ttl-seconds: 60
  heartbeat-interval-seconds: 30

SqlCachingPodsObserver also resets to a fail-open state on heartbeat/topology refresh failure to avoid stale routing decisions.

Clouddriver: Redis Priority Scheduler (opt-in)

A new Redis-based priority scheduler is available for Clouddriver caching agents.

Key points:

  • Uses Redis sorted sets and Lua scripts for atomic scheduling transitions.
  • Adds cleanup services (zombie/orphan), circuit breakers, and richer scheduler observability.
  • Requires Redis 6.2+ (ZMSCORE).

Enablement:

redis:
  scheduler:
    enabled: true
    type: priority
  agent:
    max-concurrent-agents: 100

Migration notes:

  • Legacy scalar redis.scheduler and legacy redis.parallelism are rejected.
  • redis.scheduler.parallelism is ignored in priority mode.
  • Use redis.agent.max-concurrent-agents to control concurrency for priority mode.
  • redis.agent.disabledAgents is ignored in priority mode; use redis.agent.disabled-pattern.

AWS JDBC Driver Update

The AWS JDBC driver has been updated from the deprecated aws-mysql-jdbc driver (version 1.0.0) to the AWS Advanced JDBC Wrapper.

This update adds support for IAM authentication with AWS Aurora Global Database endpoints. The previous driver did not support global database endpoint format (*.global.rds.amazonaws.com) when using IAM authentication, resulting in the error:

java.sql.SQLException: Unsupported AWS hostname '<hostname>.global.rds.amazonaws.com'.
Amazon domain name in format *.AWS-Region.rds.amazonaws.com is expected

Note: Standard database connections (without IAM authentication) continue to work as before and do not require any configuration changes.

Affected services: Front50, Orca, Clouddriver, Fiat

Configuration for IAM Authentication with Aurora Global Database

If you are using IAM authentication and want to connect to Aurora Global Database endpoints, update your JDBC connection string:

New JDBC URL format:

jdbc:aws-wrapper:mysql://<GLOBAL_ENDPOINT>:<PORT>/<DATABASE>?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.<CLUSTER_IDENTIFIER>.<REGION1>.rds.amazonaws.com,?.<CLUSTER_IDENTIFIER>.<REGION2>.rds.amazonaws.com&iamRegion=<CURRENT_REGION>

Example: If your Aurora Global Database has:

  • Global endpoint: mydb-global.global-xxxxx.global.rds.amazonaws.com
  • Primary (us-west-2): mydb.cluster-abc123.us-west-2.rds.amazonaws.com
  • Secondary (us-east-1): mydb.cluster-abc123.us-east-1.rds.amazonaws.com

Configure the JDBC URL as:

jdbc:aws-wrapper:mysql://mydb-global.global-xxxxx.global.rds.amazonaws.com:3306/front50?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.cluster-abc123.us-west-2.rds.amazonaws.com,?.cluster-abc123.us-east-1.rds.amazonaws.com&iamRegion=us-west-2

Observability Plugin Update

The Armory Observability plugin has been updated to version 1.6.1 to resolve compatibility issues with the new AWS JDBC wrapper.

Security enhancement: Url Filtering/Restriction capabilities on Artifact accounts

Starting in Armory Continuous Deployment 2.36.6, we have enabled to capability to filter/restrict urls that can be accessed per artifact accounts. This feature provides a safeguard around user input of remote urls when artifact accounts are in used in the context of a pipeline execution.

An example configuration can be found below which can be added per artifact account (http, github, helm):

artifacts:
  http:
    enabled: true
    accounts:
      - name: http_account
        urlRestrictions:
          allowedDomains:
          - mydomain.com
          - raw.github.com
          - api.github.com
          rejectLocalhost: true #default value
          rejectLinkLocal: true #default value
          rejectVerbatimIps: true #default value
          rejectedIps: [] #default value

By default the configuration blocks any local CIDR ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), localhost, link local and raw IPs. For full configuration details please refer to this configuration class

Armory Continuous Deployment 2.36.2 onwards Docker images now based on Ubuntu

The Armory Continuous Deployment 2.36.2 Docker images have been updated to use Ubuntu as the base image, replacing the previous Alpine base. This change enhances compatibility with various libraries and tools, improving overall stability and performance. Additionally, the new images now include all the necessary dependencies for authentication on a Kebreros server.

Pipeline Reference feature is now able to Lazy load the pipeline reference pipelines

In Spinnaker OSS release 1.35.0 Orca introduced a feature flag to reduce the execution size in nested pipelines by converting PipelineTrigger to PipelineRefTrigger:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      orca:
        executionRepository:
          sql:
            enabled: true
            pipelineRef:
              enabled: true

When enabled, child pipeline execution ids are stored in sql instead of the entire child pipeline execution context.

In Armory CD 2.36.2 this functionality is now extended to make the in-memory representation of the pipelines aware of the pipeline reference and to not load in-memory a full representation of the pipeline context. To enable this feature in Deck add the following in settings-local.js:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      deck:
        settings-local.js: |
          ...
          window.spinnakerSettings.feature.pipelineRefEnabled = true;
          ...

Orca PR 4842 Deck PR 10164

New pipeline stage configuration backOffPeriodMs

A new configuration option backOffPeriodMs has been added to the pipeline stage configuration. This option allows users to specify a back-off period in milliseconds for stages that may need to retry operations after a failure. Before this, pipeline authors had no control over the backoff period. It came from either spinnaker configuration properties or implementations of RetryableTask.getDynamicBackoffPeriod.

Additionally, the following configuration options have been added that allow admins to specify globablly the backoff period:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      orca:
        tasks.global.backOffPeriod:
        tasks.<cloud provider>.backOffPeriod:
        tasks.<cloud provider>.<account name>.backOffPeriod:

Orca PR 4841

Java upgrades

Java 17 is now the default source and target. Java 11 support has been removed entirely. Please note you may need to add the following JAVA_OPTS options: --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED to clouddriver if using GCP accounts due to credentials parsing of certificates. These can set in the service-settings config . These configs are likely to be added to the defaults in all future releases

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    service-settings:
      clouddriver:
        env:
          JAVA_OPTS: "--add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED"

Performance Improvements for Pipeline Executions

This release includes several optimizations to improve pipeline execution times, particularly for complex pipeline structures.

Key Improvements

  1. Memorize the anyUpstreamStagesFailed extension function to improve time complexity from exponential to linear
  2. Optimize getAncestorsImpl to reduce time complexity by a factor of N, where N is the number of stages in a pipeline
  3. Optimize StartStageHandler to only call withAuth (which calls getAncestorsImpl) when

These enhancements significantly reduce pipeline execution time, with the most notable gains observed in dense pipeline graphs. For example, in the ComplexPipeline.kt test scenario, execution time improved from not completing at all to approximately 160ms.

PR 4824

Performance Improvements for SQL Backend

This release enhances the performance of SQL-backed pipeline queries by optimizing database operations, particularly for the API call:

/applications/{application}/pipelines?expand=false&limit=2

which is frequently initiated by Deck and forwarded through Gate to Orca.

Key Improvements

  • Improved Query Efficiency: Optimized the retrieval of pipeline execution data, significantly reducing database query times.
  • Refactored TaskController: Externalized configuration properties to allow better flexibility and tuning.
  • Enhanced getPipelinesForApplication()
    • Limits the number of pipeline config IDs queried.
    • Processes multiple pipeline config IDs simultaneously.
    • Introduces multi-threading to handle batches efficiently.

PR 4804

Feature: Read Connection Pool for SQL Execution Repository

This release introduces support for a dedicated read connection pool for specific read-only database queries in SqlExecutionRepository

Key Improvements

  1. New “read” Connection Pool: Allows read operations to be routed to a separate connection pool.
  2. Configurable Read Pool: Users can define an additional read connection pool in the SQL configuration.
  3. Ensures Data Consistency: Some read queries still rely on recently written data and are not yet converted to use a read replica due to potential replication lag.

Configuration Example

To enable the read connection pool, add the following configuration:

sql:
  connectionPools:
    default:
      <...>
    read:
      jdbcUrl: jdbc:...
      user: orca_service
      password:
      connectionTimeoutMs:
      validationTimeoutMs:
      maxPoolSize:
      minIdle:
      maxLifetimeMs:
      idleTimeoutMs:

PR 4803

Enhanced pipeline batch update feature

Gate

Adds a new enpdoint, POST /pipelines/bulksave, which can take a list of pipeline configurations to save. The endpoint will return a response that indicates how many of the saves were successful, how many failed, and what the failures are. The structure is

[
   "successful_pipelines_count"  : <int>,
   "successful_pipelines"        : <List<String>>,
   "failed_pipelines_count"      : <int>,
   "failed_pipelines"            : <List<Map<String, Object>>>
]

There are a few config knobs which control some bulk save functionality. The gate endpoint invokes an orca asynchronous process to manage saving the pipelines and polls until the orca operations are complete.

controller:
  pipeline:
    bulksave:
      # the max number of times gate will poll orca to check for task status
      max-polls-for-task-completion: <int>
      # the interval at which gate will poll orca.
      taskCompletionCheckIntervalMs: <int>

Orca

Updates Orca’s SavePipelineTask to support bulk saves using the updated functionality in the front50 bulk save endpoint.

With Orca PR 4781, keys from the stage context’s outputs section can now be removed (there by reducing the context size significantly). At present the following tasks support this feature:

  • PromoteManifestKatoOutputsTask
  • WaitOnJobCompletionTask
  • ResolveDeploySourceManifestTask
  • BindProducedArtifactsTask

The Orca PR 4788 introduced a new CheckIfApplicationExists task that is added to various pipeline stages to check if the application defined in the pipeline stage context is known to front50 and/or clouddriver. The following config knobs are provided so that all of these stages can be individually configured to not perform this check if needed. Default value is set to false for all of them.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      orca:
        tasks:
          clouddriver:
            promoteManifestKatoOutputsTask:
              excludeKeysFromOutputs:
              - outputs.createdArtifacts
              - outputs.manifests
              - outputs.boundArtifacts
            waitOnJobCompletionTask:
              excludeKeysFromOutputs:
              - jobStatus
              - completionDetails
            resolveDeploySourceManifestTask:
              excludeKeysFromOutputs:
              - manifests
              - requiredArtifacts
              - optionalArtifacts
          core:
            bindProducedArtifactsTask:
              excludeKeysFromOutputs:
              - artifacts

Separate config knobs are also provided at the AbstractCheckIfApplicationExistsTask level to determine if clouddriver needs to be queried for the application or not. It is by default set to true, so it is an opt-out capability. the config property is:

tasks:
  clouddriver:
    checkIfApplicationExistsTask:
      checkClouddriver: false   # default is true

This feature runs in audit mode by default which means if checkIfApplicationExistsTask finds no application, a warning message is logged. But when audit mode is disabled through the following property, pipelines fail if application is not found:

tasks:
  clouddriver:
    checkIfApplicationExistsTask:
      auditModeEnabled: false  # default is true

Front50

Batch update operation in front50 is now atomic. Deserialization issues are addressed. Configurable controls are added to decide whether cache should be refreshed while checking for duplicate pipelines:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    profiles:
      front50:
        controller:
          pipeline:
            save:
              refreshCacheOnDuplicatesCheck: false // default is true

Batch update call now responds with a status of succeeded and failed pipelines info. The response will be a map containing information in the following format:

[
  "successful_pipelines_count"  : <int>,
  "successful_pipelines"        : <List<String>>,
  "failed_pipelines_count"      : <int>,
  "failed_pipelines"            : <List<Map<String, Object>>>
]

Here the value for successful_pipelines is the list of successful pipeline names whereas the value for failed_pipelines is the list of failed pipelines expressed as maps.

Spinnaker community contributions

Armory CD 2.36.8 tracks the latest published upstream 1.36.x patch line.

Upstream references:

Notable upstream changes:

  • Clouddriver: improved ECS target-group health evaluation and several AWS/GCP reliability fixes.
  • Gate/Echo: SAML signing behavior fix and duplicate manual-judgment notification fix.
  • Clouddriver (Google): async operation retry/status polling to prevent progressing pipeline tasks before cloud operations settle.

Detailed updates

Bill Of Materials (BOM)

Expand to see the BOM

version: 2.36.8
timestamp: 2026-03-05
services:
  clouddriver:
    version: 2.36.8
    commit: 9238966167d0036449c1cf1610d4e40d30a59a95
  deck:
    version: 2.36.8
    commit: 54a2aada8cb187554536daeb8b8b2858714d1afe
  dinghy:
    version: 2.36.8
    commit: d36fdf5b496b18212275686d4c9069d72c9dbeb1
  echo:
    version: 2.36.8
    commit: c7a79f742083c508cd28330814925e8f3906d067
  fiat:
    version: 2.36.8
    commit: e77853e0322014f3b3f8911d9d6f2431830c192c
  front50:
    version: 2.36.8
    commit: 5f8f39172e88b3abe49bab28e2fcb786b8653bf0
  gate:
    version: 2.36.8
    commit: f99a459232f70e19a719a1962f7c6fcee9218750
  igor:
    version: 2.36.8
    commit: 30cab7aaabdfe08c05c37146ab644555cf413513
  kayenta:
    version: 2.36.8
    commit: 2ce818eed3873004412758a0f731cf8420df8594
  orca:
    version: 2.36.8
    commit: 178d4b576e7b8136c42e0baa108cbf2730f6cec8
  rosco:
    version: 2.36.8
    commit: 8e35f1c3560b3b8f7de6fc4a35718b4aee98a47c
  terraformer:
    version: 2.36.8
    commit: 8453d42107fda5f0c315c8459f523e9182805832
  monitoring-daemon:
    version: 2.26.0
  monitoring-third-party:
    version: 2.26.0
dependencies:
  redis:
    version: 2:2.8.4-2
artifactSources:
  dockerRegistry: docker.io/armory

Armory

Armory Clouddriver - 2.36.7…2.36.8

  • fix(validation): URL validation hardening on underscore/authority handling (upstream #7428)
  • fix(cats-sql): make SqlUnknownAgentCleanupAgent sharding-aware (upstream #7431)
  • refactor(sharding): pluggable sharding strategy for caching pods (upstream #7432)
  • feat(scheduler): add Redis priority scheduler (upstream #7433)

Armory Fiat - 2.36.7…2.36.8

Armory Front50 - 2.36.7…2.36.8

Armory Orca - 2.36.7…2.36.8

  • fix(validation): URL restriction parsing/validation alignment for webhook restrictions (upstream #7428)

Armory Igor - 2.36.7…2.36.8

Terraformer™ - 2.36.7…2.36.8

Armory Rosco - 2.36.7…2.36.8

Armory Gate - 2.36.7…2.36.8

Armory Echo - 2.36.7…2.36.8

Armory Deck - 2.36.7…2.36.8

Armory Kayenta - 2.36.7…2.36.8

Dinghy™ - 2.36.7…2.36.8

Spinnaker

Spinnaker Igor - 1.36.1

Spinnaker Rosco - 1.36.1

Spinnaker Gate - 1.36.1

Spinnaker Echo - 1.36.1

Spinnaker Deck - 1.36.1

Spinnaker Orca - 1.36.1

Spinnaker Kayenta - 1.36.1

Spinnaker Front50 - 1.36.1

Spinnaker Clouddriver - 1.36.1

Spinnaker Fiat - 1.36.1


Last modified March 5, 2026: (de460314)