Treatment stepOnTerminable

cicd/steps::stepOnTerminable

Configuration

⬡ logger: log/logger::Logger
⬡ runner: cicd/runners::CicdRunnerEngine

Parameters

↳ var commands: Vec<Command> = [] (process/command::Command)
↳ var environment: Option<Environment> = _ (process/environment::Environment)
↳ var executor_name: Option<string> = _
↳ var name: string
↳ var out_file: Option<string> = _
↳ var out_filesystem: Option<string> = _
↳ var stop_on_failure: bool = true

Inputs

⇥ terminate: Block<void>
⇥ trigger: Block<void>

Outputs

↦ completed: Block<void>
↦ data: Stream<byte>
↦ error: Block<void>
↦ failed: Block<void>
↦ finished: Block<void>
↦ started: Block<void>
↦ success: Block<void>
↦ terminated: Block<void>

Runs step on given runner.

Uses the runner to run given commands on executor designated by executor_name with environment.

name serves as identifying purpose.

After commands run, and if they all succeed, the out_file from out_filesystem is extracted and streamed through data.

About the outputs signals:

• started is emitted once first command is started;
• finished is emitted once execution of commands ends in any case;
• failed is emitted if executor failed to run commands (no further commands are executed);
• completed is emitted once and if commands runs to completion;
• success is emitted if commands run successfully, returning exit code 0;
• error is emitted if commands run exited with exit code different from 0.

At any moment, terminate signal can be triggered, stopping the run of currently running command (executors may have different strategies, usually killing the process) and cancelling subsequent ones. In that case, terminated and finished are emitted but not failed nor error.

ℹ️ commands can be empty, as well as environment and executor_name set to none, making stepOn to directly extract out_file from out_filesystem. out_file and out_filesystem can be none and data stream will be closed without emitting reading error.

⚠️ environment may rely on the executor abilities to be correctly setted up. Within containers it is usually passed to /usr/bin/env command, which then require it to be present to use specific environment. Also, while present in many base images, abilities of /usr/bin/env may be limited. Distributions such as Alpine Linux includes a basic env command unable to set working directory, requiring to run apk add coreutils-env beforehand if working_directory of given environment is used.