Execution plugin package.
Execution plugin utilities.
check_error(ctx, error_check_func=None, reraise=False)¶
create_process_config(script_path, process, operation_kwargs, quote_json_env_vars=False)¶
Updates a process with its environment variables, and return it.
Gets a dict representing a process and a dict representing the environment variables. Converts each environment variable to a format of:
<string representing the name of the variable>: <json formatted string representing the value of the variable>.
Finally, updates the process with the newly formatted environment variables, and return the process.
process updated with its environment variables
Utilities for managing globals for the environment.
globals()call in a freshly loaded module.
The implementation of this function is likely to raise a couple of questions. If you read the implementation and nothing bothered you, feel free to skip the rest of this docstring.
First, why is this function in its own module and not, say, in the same module of the other environment-related functions? Second, why is it implemented in such a way that copies the globals, then deletes the item that represents this function, and then changes some other entries?
Well, these two questions can be answered with one (elaborate) explanation. If this function was in the same module with the other environment-related functions, then we would have had to delete more items in globals than just
create_initial_globals. That is because all of the other function names would also be in globals, and since there is no built-in mechanism that return the name of the user-defined objects, this approach is quite an overkill.
But why do we rely on the copy-existing-globals-and-delete-entries method, when it seems to force us to put ``create_initial_globals`` in its own file?
Well, because there is no easier method of creating globals of a newly loaded module.
How about hard coding a ``globals`` dict? It seems that there are very few entries: ``__doc__``, ``__file__``, ``__name__``, ``__package__`` (but don’t forget ``__builtins__``).
That would be coupling our implementation to a specific
globalsimplementation. What if
globalswere to change?
Execution plugin exceptions.
ProcessException(stderr=None, stdout=None, command=None, exit_code=None)¶
Raised when local scripts and remote SSH commands fail.
ScriptException(message=None, retry=None, retry_interval=None)¶
Used by the
ctxproxy server when task.retry or task.abort are called by scripts.
Local execution of operations.
run_script(ctx, script_path, process, **kwargs)¶
Entry point functions.