Skip to content

0.11.0
Compare
Choose a tag to compare
@flosell flosell released this 23 Oct 18:40
· 289 commits to master since this release
0.11.0
This tag was signed with the committer’s verified signature. The key has expired.
flosell Florian Sellmayr
GPG key ID: 70794554AF507349
Expired
Learn about vigilant mode.
dcb2cbc
  • Improvements:
    • Keeps a history of pipeline structure if persistence component supports it (#131, #6); Implemented for default persistence
    • Improved performance and resource consumption by compressing and throttling step-result update events (#140).
      Can be configured with the configuration parameter :step-updates-per-sec.
    • Introduced event :step-result-update-consumed to indicate that a step update was consumed and is available in the pipeline state #136
  • Bug fixes:
    • Fix deadlock occurring when steps write a lot of step-results in quick succession and step results are inherited by their parents (as in chaining) (#135, #140)
  • API changes:
    • New state handling (#131):
      • Protocols in lambdacd.state.protocols replace lambdacd.internal.pipeline-state/PipelineStateComponent which is now deprecated. Custom persistence-mechanisms need to migrate.
      • Added facade lambdacd.state.core for all state-related functionality. Access directly to PipelineStateComponent is now deprecated.
      • lambdacd.presentation.pipeline-state/history-for should now be called with ctx; Calling it with a build-state (the result of lambdacd.internal.pipeline-state/get-all) still works but is now deprecated.
      • lambdacd.presentation.unified/unified-presentation is now deprecated, use lambdacd.presentation.unified/pipeline-structure-with-step-results instead
    • The current pipeline-definition can now be accessed as :pipeline-def in ctx
  • Breaking Changes:
    • Moved pipeline-state-updater from lambdacd.internal.pipeline-state to lambdacd.state.internal.pipeline-state-updater and refactored interface. As this is an internal namespace, it should not affect users unless they customized LambdaCDs startup procedure to a large degree.
    • The fix for #135 changes the behavior of step result inheritance by introducing a sliding window that compresses several step result update events into one: Steps inheriting their childens results via the :unify-status-fn or :unify-results-fn (e.g. chaining steps) might not pass on intermediate update events; the ultimately resulting unified step result will remain the same.
    • Removed nil-check from DefaultPipelineState/{update,consume-step-result-update}: This was meant as a convenience for internal tests that set up incomplete components. Tests have since been fixed so this is no longer necessary. If you are impacted by this issue, make sure you create DefaultPipelineState with new-default-pipeline-state
Assets 2