Skip to content

Tags: phanikumarp/orca

Tags

v7.52.0

Toggle v7.52.0's commit message
feat(secrets/gcs): Support for decrypting spinnaker secrets in GCS (s…

…pinnaker#3205)

v7.51.2

Toggle v7.51.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(titus): use labels as override only for titus health providers (s…

…pinnaker#3221)

Today, when determining health providers on Titus, we look at the labels on the source server group.
For AWS, we look at front50 if the app has the platform only override set.
Make Titus work similarly but allow the labels to be used as override (if they exist)

v7.51.1

Toggle v7.51.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(Kayenta): Change exception type to kork.UserException (spinnaker#…

…3218)

* fix(Kayenta): Change exception type to kork.UserException

v7.51.0

Toggle v7.51.0's commit message
fix(pipelines): Fixed interpretation of missing startTime during inst… (

spinnaker#2820)

* fix(pipelines): Fixed interpretation of missing startTime during instrumentation

Fixes spinnaker/spinnaker#4244

There are conditions in which CompleteStageHandler can be called without
having a startTime set. Often this is because an exception was thrown
before the startTime was set, but there are various guards within
StartStageHandler as well.

Previously when this happened, a StartTime of 0 was used. This is
particularly bad because the 40-years worth of nanoseconds that is
spit out of spectator is beyond the resolution of "double" for metric
stores that use double for time. This fix changes the assumption
to be the end time, resulting in assuming 0 time. Not that this could
possibly be a different type of issue if the underlying problem was
something else, such as StartStageHandler not even being called for some
reason.

In addition I set the startTime at the beginning of the try block where
exceptions may be thrown in order to ensure there is a startTime when
going through that control flow. I think this might be messy depending
on how time and state are used because it has a startTime but is not in
the RUNNING state. There does not seem to be an appropriate state definition
for this particular phase and am not sure the implications of adding one.
I also dont know if moving the startTime so it includes this extra check
has other implications. If so then the startTime could be reset where it
is currently set.

* defer RUNNING status until after the extra initial store.

Being in the RUNNING state affected the handler guard checking
for NOT_STARTED (line 71) causing it to be ignored. I dont
really understand the control flow here, and could not follow
along in a debugger because kotlin/mockito jumps all over the
place making it impossible for me to grok that way. I suspect
there is a better fix and could involve adding another status
between NOT_STARTED and RUNNING but that is beyond my level
of intimacy with the model here.

fixed tests to accomodate the second storeStage call.

v7.50.0

Toggle v7.50.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
chore(core): Adding stage.toString() (spinnaker#3209)

* chore(core): Adding stage.toString()

- added a toString method with the stage id & execution id

* - PR feedback

v7.49.1

Toggle v7.49.1's commit message
fix(rollback): pass authentication context and consider errors fatal

This avoids a potentially dangerous scenario where we roll back to a server
group of size 0 and fail to look it up for some reason, e.g. if it is in
a restricted account and we fail to pass the credentials along to clouddriver.

v7.49.0

Toggle v7.49.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
feat(tasks): attach notifications to execution (spinnaker#3206)

v7.48.0

Toggle v7.48.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(monitored deploy): send complete notification on failure & add sh…

…rink cluster (spinnaker#3199)

* fix(monitored deploy): send complete notification on failure
When deploy fails we need to sent completion notification to the deployment monitor

* fix(monitored deploy): add shrink cluster ability
Added ability to shrink cluster at the end of deploy (same as red/black, with `maxRemainingAsgs` param)

v7.47.2

Toggle v7.47.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(RRB & MD): pin and unpin the correct server group (spinnaker#3197)

During rolling redblack (or monitored deploy), use the determined source server group to pin/unpin.
This used to live in the deploy preprocessor, but the deploy preprocessor runs too early to be useful (it runs before we run determineSourceServerGroup task).
This means it can pick the wrong ASG to pin! in the following scenario:

```
ASG v2 - being deployed
ASG v1 - Disabled
ASG v0 - Enabled
```

before this change, we would pin/unpin `v1` which is clearly wrong ASG to pin.

NOTE: currently the code is duplicated in RRB and MD strategies. I will do another PR with a refactor to make them share code (it's proving harder than anticipated to make this refactor actually nice)

v7.47.1

Toggle v7.47.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(monitored deploy): make reason singular (spinnaker#3195)

there is no point having an array of reasons from deployment monitor, making it a single object