Skip to content

Tags: benjaminws/orca

Tags

v6.26.0

refactor(core): Change type to Instant (spinnaker#2091)

* refactor(core): Change type to Instant

v6.18.8

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(queue): Fix execution type based clouddriver routing (spinnaker#2089

)

v6.18.7

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
feat(orca-kayenta): move canaryExecutionRequest and application to to…

…p-level (spinnaker#2084)

v6.18.6

fix(after stages): Allow for just-in-time planning of after stages

This is a bridge to the 6.5.x branch of Orca where after stages are _always_ planned just in time. During deployment this can be an issue if a 6.5.x instance starts a stage (and does not plan after stages) and a 6.4.x instance tries to complete the stage (finding no before stages or tasks and no planned after stages).

v6.25.2

fix(triggers): Git triggers must have a non-null hash

v6.25.1

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(clouddriver): Fix NPE while searching for ancestor stage (spinnak…

…er#2037)

v6.25.0

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(resize): Support both 'asgName' and 'serverGroupName' (spinnaker#…

…2071)

Noticed the inconsistency when investigating a recent `orca` issue.

It would be nice to standardize on `serverGroupName` but we still have
operations (like this one!) expecting `asgName`.

v6.18.5

fix(triggers): Git triggers must have a non-null hash

v6.24.1

chore(debug): Log what went wrong if we fail to plan after stages (sp…

…innaker#2077)

v6.24.0

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
refactor(persistence): Unify Jedis/Dynomite Repos (spinnaker#2070)

Having separate Jedis vs. Dynomite execution repositories posed a number of
problems around live migrations in a dual repository configuration.

This was partially due to the Dynomite repository using a different
scheme for key names, in order to utilize Dynomite hash sets, I.e.
[pipeline:abc-123, pipeline:abc-123:stageIndex] turns into
[{pipeline:abc-123}, {pipeline:abc-123}:stageIndex]. To support
live migrations, we need to be able to find executions in either
the current or previous store regardless of type or key names.
This implements that logic, as well as the ability to generate key
names based on the class type of each configured RedisClientDelegate.
This should enable Redis <---> Dynomite migrations in either direction.