Default Actions
This category contains default nodes, designed to facilitate common automation activities and implement business logic directly out of the box. These predefined nodes cover a wide array of functionalities, making them immediately useful for many standard automation tasks.
The Bash Node in Kubeark is a type of execution node designed for running Bash scripts or commands within a workflow. It allows users to incorporate shell scripting into their data processing or automation tasks, facilitating operations like file manipulation, system administration, and execution of software or commands available in a Bash environment. By leveraging the Bash Node, users can execute custom scripts or commands on a Linux-based executor, enabling a wide range of operations that can be scripted in Bash, such as:
- Data processing tasks, like file sorting, filtering, and aggregation.
- System operations, including file system management, process control, and environment configuration.
- Interfacing with other software tools or services that can be controlled via command-line interfaces.
To use the Bash Node, you would typically specify the script or commands to be executed, along with any necessary input parameters or environment variables. Here is a detailed breakdown of the configuration options:
- Name: The identifier for this particular Bash Node in your workflow.
- Condition: This field is where you specify the condition under which this node will be executed. If you set a condition, the node will run its script only when that condition evaluates to true.
- On Error: Determines what happens if an error occurs during the execution of the Bash script. Options might include stopping the workflow, retrying the node, skipping it, or executing a compensatory action.
- Input:
- Environment Variables: Here, you can declare environment variables that the Bash script will use. These could be paths, configuration settings, or any other data that shouldn't be hardcoded into the script.
- Script: The main field where you input the actual Bash commands or script to be executed. This script can perform a wide array of tasks, from file manipulation to running applications and services.
When this node is activated, the Bash script provided will be run in a shell environment. The ability to execute Bash commands adds powerful capabilities to your workflow, allowing for complex operations that take full advantage of the host system's features and installed tools.
Deno is a JavaScript/TypeScript runtime with secure defaults and great developer experience. It's similar to Node.js but includes some key differences, like security defaults that restrict file, network, and environment access unless explicitly enabled. Here is a description of the Deno arguments required for configuring this node:
- Name: This is where you name your Deno node for identification within your workflow.
- Condition: Conditions determine when this node will execute within your workflow. If a condition is set, the Deno script will only run when the condition is met.
- On Error: This defines the behavior of the workflow if the Deno node encounters an error during execution. The action could be to stop the workflow, skip the error, retry, and so forth.
- Vault: This would be used to select secure storage for sensitive data like API keys or passwords. Scopes can be defined to limit access. Please refer to Local Vault
- Input: Here, you would provide any input data the Deno script needs. Inputs are typically key-value pairs that the script can use.
- Environment Variables: Similar to inputs but specifically for environment variables that your Deno script may require to run, such as configuration settings that should not be hard-coded into the script.
- Packages: While Deno doesn't use npm, and thus does not have a package.json file like Node.js, this section might be used to specify third-party modules or dependencies that your script requires. In Deno, modules are imported directly from URLs.
To use this node, you would need to provide the necessary script, configure any inputs or environment variables your script requires, and set up error handling according to your workflow's needs. The configured node can then execute TypeScript or JavaScript within the secure Deno environment as part of a larger automated process.
A Dotnet (.NET) node allows you to run C# (or other .NET-compatible language) scripts or programs within the context of an automation or data-processing workflow. Here's a breakdown of the configuration options available:
- Name: This is the identifier for the .NET node within the workflow. It helps you distinguish between different nodes when managing or reviewing workflows.
- Condition: This optional field allows you to specify a condition under which the .NET node will be executed. If a condition is given, the node will only run its .NET script when that condition is true.
- On Error: Here, you can define what should happen if the .NET node encounters an error during its execution. Options might include stopping the workflow, skipping the node, retrying, etc.
- Vault: If your .NET script needs to use sensitive data, such as passwords or API keys, you would use this section to select the appropriate secure storage - see Local Vault
- Input: In this section, you would specify any input data that the .NET script requires. Inputs are generally in the form of key-value pairs that the script can consume.
- Environment Variables: These are key-value pairs that the .NET node's environment will recognize. They are similar to inputs but are used specifically for environmental configuration rather than script inputs.
- NuGet Packages: Since .NET applications often rely on external libraries, this section allows you to specify any NuGet packages that your script depends on. NuGet is the package manager for .NET, providing a collection of libraries and tools for .NET developers.
When you use this node, you would write a .NET script or program and input it into the system, specify any dependencies it has via NuGet, and configure any inputs or environment variables required. This node then processes the .NET code within the context of the larger workflow, which can involve multiple other nodes, potentially written in different languages or performing different tasks.
This node is designed to run code written in the Go programming language, often referred to as Golang. Here’s a breakdown of the configuration options shown:
- Name: This is where you give your Golang node a unique identifier for reference within your workflow.
- Condition: If specified, this determines the conditions under which the Golang node will execute. You can configure this to run the node only when certain criteria are met within your workflow.
- On Error: This configuration dictates the course of action if the Golang node encounters an error during its execution. Options might include actions like stopping the workflow, skipping the node, retrying the operation, etc.
- Input: Here you would input any data that the Golang script requires to run, such as parameters for functions within the Go code.
- Environment Variables: These are the environmental parameters that your Go code will use during execution. They are system-level information that can affect how your script runs.
- Modules: Since Go uses modules to manage dependencies, this section would be where you specify external packages or modules that your Go code depends on.
In practice, after setting the name and, if necessary, the condition for the execution, you would provide your Go code, ensure that all necessary modules and environment variables are specified, and set your on-error action. This Golang node can then be used as part of your workflow to automate tasks using Go, integrating with other nodes and services as required.
This type of node is designed to perform HTTP requests to communicate with web services. Here is the breakdown of the configuration fields:
- Name: You assign a unique identifier to the node, in this case, it's node_d6d57f0e, which helps you identify it within your workflow.
- Condition: This optional field allows you to define a condition under which the HTTPRequest node should be triggered. If set, the node will only execute the HTTP request when the condition evaluates to true.
- On Error: Here you decide what action should be taken if an error occurs during the HTTP request. Options might include stopping the workflow, retrying the request, or proceeding with the next steps without taking any action.
- Input: Under this section, you configure the details of the HTTP request.
- Method: This is where you specify the HTTP method to use for the request, such as GET, POST, PUT, DELETE, etc. In your screenshot, GET is selected.
- URL: You enter the URL to which the HTTP request will be sent.
- Authentication: If the endpoint requires authentication, you select the type here. In your screenshot, Basic authentication is selected, which requires a username and password. Username: You provide the username required for authentication. Password: You provide the password corresponding to the username.
- Headers: HTTP headers can be specified here to include additional information with the request, such as 'Content-Type' or 'Authorization' information.
- Body: If the request method is one that allows a body, such as POST or PUT, you can provide the data to be sent with the request here. This field isn’t visible in your screenshot but would typically be included for methods that support a request body.
Once configured, the HTTPRequest node will perform the specified HTTP request when triggered within the workflow. The node can handle the response, pass data to subsequent nodes, and integrate with different parts of the system or external services as part of an automated process.
kubectl is a command-line tool that allows you to run commands against Kubernetes clusters to deploy applications, inspect and manage cluster resources, and view logs. Here's what each part of the node configuration is for:
Name: This is the identifier for the node within your workflow. Here, it is set to node_edd3d087. Condition: This is where you can define conditions that must be met for the kubectl node to execute. It acts as a form of flow control, executing the kubectl command only when specific criteria are satisfied. On Error: This setting dictates what should happen if an error occurs during the execution of the kubectl command. You can typically choose to stop the workflow, ignore the error, or retry the command. Vault: The vault is used for securely storing and accessing secrets, like passwords or API tokens. This could be necessary if your kubectl command interacts with a Kubernetes cluster that requires authentication. Please refer Local Vault Input: Cluster Id: This refers to an identifier for a Kubernetes cluster within the system. The kubectl commands will be executed against the cluster with this ID. Api Token: This is the authentication token that kubectl will use to authenticate against the Kubernetes cluster API. Args: Here, you would specify additional arguments or parameters to pass to the kubectl command. This field might include the specific kubectl commands and options you want to run.
By configuring and running this node, you can automate Kubernetes operations as part of a larger workflow, for instance, deploying applications, managing resources, or gathering information from your Kubernetes cluster.
The Playwright node configuration screens you've provided are for setting up a node that uses Playwright within a workflow. Playwright is a Node library that enables developers to automate browser tasks such as testing web applications across various browsers.
Let's go through the configuration options:
- Name: This field is for the unique identifier of the Playwright node in your workflow, here named node_807b0760.
- Condition: This optional field allows you to define conditions for the node's execution. If specified, the node will execute its actions only when the set condition(s) is true.
- On Error: This determines what should happen if an error occurs during the Playwright node's execution. You might choose to stop the process, ignore the error, retry the action, etc.
- Input: This section contains various configuration options:
- Config: This sub-section typically contains settings for how Playwright should operate.
- Device: Specifies the device emulation settings for the browser, e.g., 'Desktop Chrome'.
- Retries: The number of times the node should retry the action in case of failure.
- Timeout: Sets the maximum time to wait for the action to complete.
- Storage State: Contains settings related to browser state like cookies and local storage.
- Cookies: You might be able to specify particular cookie data here.
- Origins: This could refer to the origin URLs for which the storage state (like cookies, local storage) applies.
- Storage State Path: The path to the file with saved storage state that Playwright can use to initialize the browser context.
- Environment Variables: Here you can set up environment variables that your Playwright scripts may require.
- Setups: Specify custom setup scripts or configurations that need to be run before the main Playwright actions.
- Spaces: A workspace or a specific area within the workflow platform where this Playwright node is applicable.
The Playwright node allows you to automate browser actions as part of your workflows. You could use it for tasks like scraping web data, automating form submissions, or performing end-to-end tests on web applications.
This node is designed to execute Python code as part of an automated sequence or data processing pipeline. Here’s a rundown of the configuration options shown:
- Name: This is the unique identifier for the node in your workflow, which you can use to reference the node.
- Condition: An optional setting where you can specify conditions that must be met for the node to execute. If a condition is provided, the node will only run its Python script when that condition is true.
- On Error: Here, you define what should happen if the node encounters an error while executing the Python code. Options typically include stopping the workflow, skipping the node, or attempting to retry.
- Input: Under this section, you configure the inputs that the Python script needs.
- Environment Variables: These are variables that the Python environment will recognize and can affect script execution. You can add environment-specific variables that your script needs here.
- Packages: If your Python script depends on third-party packages, you can list them here. This ensures that the necessary packages are available to the Python environment when the script runs.
- Script: This is the most important part. It's where you input the actual Python code to be executed. This script can do anything that Python is capable of, given the node's permissions and available libraries, such as data manipulation, calling APIs, processing files, and more.
When this node is executed within a workflow, it will run the specified Python script with the given environment variables and packages. This allows you to automate tasks using Python's powerful capabilities directly within your workflow.
This node is designed to execute commands on a remote server through an SSH protocol, which provides a secure channel over an unsecured network. Here’s how you would use the fields in this configuration:
- Name: Assign a unique identifier to this SSH node in your workflow, in this case, node_ed726d50.
- Condition: Define a condition that determines when this node should be executed. If set, the node will only perform its action when the specified condition evaluates to true.
- On Error: Decide the behavior of the workflow if there's an error during the SSH command execution. Options usually include stopping the workflow, retrying the command, or continuing with subsequent actions.
- Vault: If the SSH login credentials or private keys are stored in a secure vault, you can specify which vault to access. Use this section to select the appropriate secure storage - see Local Vault
- Input: Provide the necessary information to make an SSH connection:
- Username: The SSH username for the remote server.
- Address: The address of the remote server you want to connect to, typically an IP address or a domain name.
- Password: The password associated with the SSH username. It's one way to authenticate the SSH session.
- Private Key: An alternative to using a password, you can authenticate via a private key if the remote server supports key-based authentication.
- Script: The actual shell commands or a script that you want to execute on the remote server. It's entered in the large text field.
When triggered, the SSH node will establish a secure connection to the specified remote server using the provided credentials. Once connected, it will execute the given commands or script. This can be useful for automating deployment tasks, system administration, or any situation where remote server control is needed within a workflow.
