a library to define a continuous delivery pipeline in code
:status :dead (#134)junction did not behave like a sequential step, i.e. it did not pass the results of the condition to the arguments of the branch steps (#162)lambdacd.stepresults.merge/merge-step-results default behavior consistent with other step-result merging strategies: should concatenate colliding listsBuilt-in Git-Support (lambdacd.steps.git) should be considered deprecated now and will be removed in the future. Use the more modern lambdacd-git library instead.
A couple of functions were only public by accident and should not be considered part of the public API. They will be moved or become private in the future:
lambdacd.presentation.pipeline-state/not-retriggered?
lambdacd.presentation.pipeline-structure/pad
lambdacd.presentation.pipeline-structure/step-display-representation-internal
lambdacd.runners/should-trigger-next-build?
lambdacd.steps.control-flow/synchronize-atoms
lambdacd.steps.shell/kill
lambdacd.steps.status/choose-last-or-not-success
lambdacd.steps.support/{replace-args-and-ctx,to-fn,to-fn-with-args,unify-results}
lambdacd.ui.ui-page/{css-includes,js-includes,favicon,app-placeholder,title,header,ui-config,ui-page}
lambdacd.presentation.unified/unified-presentation is unused and therefore deprecated and will be removed in the future. Use pipeline-structure-with-step-results instead.
lambdacd.steps.support/merge-globals is no longer necessary, normal step result merging (merge-step-results,merge-two-step-results) should already conserve and merge globals just fine
A couple of functions were moved to make the package structure more clear. The existing functions still exist but are now deprecated and will be removed in the future.
lambdacd.steps.result/flatten-step-result-outputs moved to lambdacd.stepresults.flatten
lambdacd.steps.result/{merge-step-results,merge-two-step-results} moved to lambdacd.stepresults.merge
lambdacd.steps.result/*-resolver moved to lambdacd.stepresults.merge-resolvers
lambdacd.steps.status/successful-when-* moved to lambdacd.stepstatus.unify
lambdacd.steps.status/is-active? moved to lambdacd.stepstatus.predicates
lambdacd.steps.support/assoc-build-metadata! moved to lambdacd.stepsupport.metadata
lambdacd.steps.support/unify-only-status moved to lambdacd.stepstatus.unify
lambdacd.steps.support/{capture-output,printed-output,print-to-output,set-output,new-printer} moved to lambdacd.stepsupport.output
lambdacd.steps.support/{killed?,if-not-killed} moved to lambdacd.stepsupport.killable
lambdacd.steps.support/{chaining,chain-steps,always-chaining,always-chain-steps,injected-args,injected-ctx,last-step-status-wins} moved to lambdacd.stepsupport.chaining
lambdacd.ui.ui-server/ui-for moved to lambdacd.ui.core
:human-readable-build-label
:pipeline-started and :pipeline-finished (#155):pipeline-finished events (#155, #154):
lambdacd.steps.result/flatten-step-result-outputs
lambdacd.presentation.pipeline-structure/flatten-pipeline-representation
lambdacd.presentation.pipeline-structure/step-display-representation-by-step-id
lambdacd.execution was deprecated in favor of lambdacd.execution.core
:unify-status-fn parameter in execute-steps (deprecated since 0.9.4). Use :unify-results-fn instead. lambdacd.steps.support/unify-only-status can help with migrating unify-status-fns.lambdacd.internal.execution was refactored into several independent namespaces, functions were moved around, replaced or made private.
You shouldn't have dependencies on those unless you are doing something really crazy or advanced. If you did, please consider using functions in public namespaces (i.e. that don't have internal in their name).
If you have dependencies on functions that have no public equivalent, please open an issue to get this fixed.New years cleanup and bug fix release.
lambdacd.util was cleaned up or moved to separate, internal namespaces as most of this functionality was never intended to be part of the public namespace. If you depend on utility functions and feel they should be part of LambdaCDs public API, please open an issue. Specifically, the following functions are now deprecated
lambdacd.util/write-as-json
lambdacd.util/ok
lambdacd.util/bash
lambdacd.util/range-from
lambdacd.util/map-if
lambdacd.util/no-file-attributes
lambdacd.util/temp-prefix
lambdacd.util/create-temp-dir
lambdacd.util/create-temp-file
lambdacd.util/with-temp
lambdacd.util/json
lambdacd.util/to-json
lambdacd.util/put-if-not-present
lambdacd.util/parse-int
lambdacd.util/contains-value?
lambdacd.util/buffered
lambdacd.util/fill
lambdacd.util/merge-with-k-v
lambdacd.internal.execution/{kill-step-handling,report-received-kill,add-kill-switch-reporter,clean-up-kill-handling}
:use-new-event-bus true to activate it. This will become the default in upcoming releases.lambdacd.event-bus/publish (deprecated since 0.9.1), use lambdacd.event-bus/publish!! instead (or lambdacd.event-bus/publish! when being called from a go-block):step-updates-per-sec.:step-result-update-consumed to indicate that a step update was consumed and is available in the pipeline state #136lambdacd.state.protocols replace lambdacd.internal.pipeline-state/PipelineStateComponent which is now deprecated. Custom persistence-mechanisms need to migrate.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:pipeline-def in ctxlambdacd.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.: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.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
lambdacd.internal.step-id (was deprecated since 0.7.0), use lambdacd.step-id insteadThis release is broken (#133), do not use
:max-builds in config (#132). Defaults to Integer/MAX_VALUE so this should be a non-breaking changelambdacd.execution/run to the public namespace. If you were using lambdacd.internal.execution/run until now, migrate to make sure you are using the official public namespace as internal interfaces can change without notice (#128)lambdacd.core into separate namespace lambdacd.execution. lambdacd.core/{retrigger,kill-step,execute-steps,execute-step} are now deprecated and will be removed in subsequent releases. Use the equivalent functions in lambdacd.execution insteadlambdacd.steps.support/{chain,always-chain,chaining,always-chaining} now return outputs of individual chained steps (#122)lambdacd.steps.support/last-step-status-wins to coerce a step result into having the status of the last output
to make an always-chained step successful even though it had a failing step in it (#122):unify-results-fn to unify the whole step-result, not just the step status from children in core/execute-steps
:unify-status-fn parameter in core/execute-steps is now deprecated and will be removed in subsequent releases.
Use :unify-results-fn instead.