v2.36.10 Armory Continuous Deployment Release (Spinnaker™ v1.36.0)

Release notes for Armory Continuous Deployment v2.36.10.

2026/06/23 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.10, 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: ECS performance improvements

This release includes performance fixes for ECS operations. Previously, ECS loaded all data for all accounts and then filtered results, causing unnecessary overhead. ECS on-demand caching behavior has also been optimized.

Clouddriver: Lambda performance improvements

This release includes additional performance improvements for Lambda operations.

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 includes fixes that improve validation around user-supplied Git repository inputs used by GitRepo artifacts.

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

There have also been numerous enhancements, fixes, and features across all of Spinnaker’s other services. See the Spinnaker v1.36.0 changelog for details.

Detailed updates

Bill Of Materials (BOM)

Expand to see the BOM
artifactSources:
  dockerRegistry: docker.io/armory
dependencies:
  redis:
    commit: null
    version: 2:2.8.4-2
services:
  clouddriver:
    commit: a2d32de1265bca8a24307feac58f706b23fec243
    version: 2.36.10
  deck:
    commit: 69dbbdfb3765511c8ac623d4f5ad54f8c1a47566
    version: 2.36.10
  dinghy:
    commit: d36fdf5b496b18212275686d4c9069d72c9dbeb1
    version: 2.36.10
  echo:
    commit: eabb406c04f3bfba78ffab3fc2dedc4acfceb740
    version: 2.36.10
  fiat:
    commit: 8a44db140c557d219721a0be23875eada6d24306
    version: 2.36.10
  front50:
    commit: 0f05af74a344e02c25eba0b74980ba7d9cd283b3
    version: 2.36.10
  gate:
    commit: f17a329e0b491a7da919a429187fccd52da98543
    version: 2.36.10
  igor:
    commit: cb13fe4f94b5deb21d257aa96a85f5b567a449dc
    version: 2.36.10
  kayenta:
    commit: c975c3fb9d0f02aa64fee095bc5d100c80ab19b6
    version: 2.36.10
  monitoring-daemon:
    commit: null
    version: 2.26.0
  monitoring-third-party:
    commit: null
    version: 2.26.0
  orca:
    commit: 5f45aa313539a10cc51b97a68374531ce1e77165
    version: 2.36.10
  rosco:
    commit: e45eea397aaa24088cafe71638fe82accb6b89f0
    version: 2.36.10
  terraformer:
    commit: 8453d42107fda5f0c315c8459f523e9182805832
    version: 2.36.10
timestamp: "2026-06-23 10:37:12"
version: 2.36.10

Armory

Armory Front50 - 2.36.9…2.36.10

Armory Deck - 2.36.9…2.36.10

Armory Rosco - 2.36.9…2.36.10

Armory Echo - 2.36.9…2.36.10

Armory Clouddriver - 2.36.9…2.36.10

  • fix(perf): ECS loaded ALL data for ALL accounts then filtered (commit 19326d4)
  • fix(ecs): Backport fix for ECS OnDemand perf issues (commit 88226a4)
  • fix(perf): Performance improvements for Lambda operations

Armory Kayenta - 2.36.9…2.36.10

Armory Terraformer - 2.36.9…2.36.10

Armory Dinghy - 2.36.9…2.36.10

Armory Orca - 2.36.9…2.36.10

Armory Gate - 2.36.9…2.36.10

Armory Fiat - 2.36.9…2.36.10

Armory Igor - 2.36.9…2.36.10

Spinnaker

Spinnaker Front50 - 1.36.0

Spinnaker Deck - 1.36.0

Spinnaker Rosco - 1.36.0

Spinnaker Echo - 1.36.0

Spinnaker Clouddriver - 1.36.0

Spinnaker Kayenta - 1.36.0

Spinnaker Terraformer - 1.36.0

Spinnaker Dinghy - 1.36.0

Spinnaker Orca - 1.36.0

Spinnaker Gate - 1.36.0

Spinnaker Fiat - 1.36.0

Spinnaker Igor - 1.36.0


Last modified June 25, 2026: (0859abad)