Available actions
- APIs and Callbacks
- actions/humanitec/api@v1
- actions/humanitec/http@v1
- actions/humanitec/github-workflow@v1
- actions/humanitec/gitlab-pipeline@v1
- Deltas and Deployments
- actions/humanitec/apply@v1
- actions/humanitec/approve@v1
- actions/humanitec/clone@v1
- actions/humanitec/create-delta@v1
- actions/humanitec/deploy@v1
- Other
- actions/humanitec/log@v1
- actions/humanitec/fail@v1
- actions/humanitec/wait-for-readiness@v1
On this page
- APIs and Callbacks
- actions/humanitec/api@v1
- actions/humanitec/http@v1
- actions/humanitec/github-workflow@v1
- actions/humanitec/gitlab-pipeline@v1
- Deltas and Deployments
- actions/humanitec/apply@v1
- actions/humanitec/approve@v1
- actions/humanitec/clone@v1
- actions/humanitec/create-delta@v1
- actions/humanitec/deploy@v1
- Other
- actions/humanitec/log@v1
- actions/humanitec/fail@v1
- actions/humanitec/wait-for-readiness@v1
Humanitec Pipelines support many different kinds of actions that can be executed in the Steps of a Pipeline.
When used in the Pipeline, the action is specified as class://name@version
, or simply name
when using the latest version of a Humanitec native action.
jobs:
job-1:
steps:
# Fully qualified action notation
- uses: native://actions/humanitec/log@v1
...
# Simplified action notation
- uses: actions/humanitec/log
...
Each action is defined by a class, a name, and a version. The only supported action class today is native://
which defines built-in actions provided by Humanitec Pipelines. Native actions execute securely within Humanitec’s infrastructure and do not support any kind of custom code execution, process environment, or command interpolation. The version of an action is assumed to be latest
if not provided which maps to the latest available version of the Action.
APIs and Callbacks
actions/humanitec/api@v1
Executes a limited set of supported Humanitec Platform Orchestrator
API operations
as the current run-as
user. The API operation returns a status code, headers, and optional body data. This action is used to retrieve data from Environments, Deltas, Sets, or Deployments.
Input | Type | Required | Description |
---|---|---|---|
action |
string | yes | The API operation id. See the list of actions below |
data |
any | no | Additional data to send to the endpoint if supported. This will be encoded as JSON |
* |
string | no | Any remaining inputs are defined by the API operations themselves, see below |
This action returns the following outputs:
Output | Type | Description |
---|---|---|
status |
string | The response status code |
data |
any | The decoded JSON body data |
This step fails if the request is not successful.
Example use:
jobs:
job-1:
steps:
- uses: native://actions/humanitec/api@v1
id: getEnv
with:
action: getEnvironment
env_id: "development"
- uses: native://actions/humanitec/log@v1
with:
# Pick up the "data" output provided by the api action
message: "Environment data:\n ${{ toJson(steps.getEnv.outputs.data) }}"
getEnvironment(env_id)
Returns the API response for an Environment of the current Application. This includes details of the current deployments and their status. Requires an input for the env_id
.
getDeployment(env_id, deployment_id)
Returns the API response for a Deployment within an Environment of the current Application. Requires inputs for both environment_id
and deployment_id
id.
getDelta(delta_id)
Returns the API response for a Delta within the current Application. Requires an input for the delta_id
.
getDeploymentSet(set_id)
Returns the API response for a Deployment Set within the current Application. Requires an input for the set_id
.
getActiveResource(env_id, type, class, res_id?)
Returns the Active Resource state for a resource within an Environment that matches the type, class, and optional resource identifier.
actions/humanitec/http@v1
Executes a remote HTTP or HTTPS request. This can be used to issue notifications externally or trigger additional external deployment actions.
Input | Type | Required | Description |
---|---|---|---|
url |
string | yes | The HTTP or HTTPS request URL including any query parameters. The hostname must resolve to a public internet address |
method |
string | no | The HTTP request method. Defaults to GET , or to POST if data is provided |
headers |
object | no | A map of any additional HTTP request headers to send |
data |
any | no | Optional body data to send. If the data type is not a string, it will be JSON encoded |
retries |
integer | no | The number of additional retries to perform if no HTTP response was received. Defaults to 3 |
timeout_seconds |
integer | no | A timeout covering connect, request, and response reading. Defaults to 5 seconds |
The step fails if the response status code is >= 300 or if no response was received within the configured timeout.
This action returns the following outputs:
Output | Type | Description |
---|---|---|
status |
string | The response status code |
data |
any | Returns up to 10KB of the raw body data. Any surplus will be dropped |
Example use:
jobs:
job-1:
steps:
- uses: native://actions/humanitec/http@v1
id: httpPost
with:
url: "https://my.external.service.com/path/to/endpoint"
method: "POST"
headers:
Content-Type: "application/json"
Authorization: "Bearer ${{ inputs.token }}"
data:
some: "data"
passed: "in"
- uses: native://actions/humanitec/log@v1
with:
# Pick up the "data" output provided by the http action
message: "Response data:\n ${{ steps.httpPost.outputs.data }}"
actions/humanitec/github-workflow@v1
This action triggers a GitHub Workflow execution and waits until it completes or the Humanitec Pipeline Job times out. The inputs define which repo, branch, and workflow file to execute as well as the inputs to provide.
This action requires a GitHub access token to be present in the Application secrets.
Input | Type | Required | Description |
---|---|---|---|
repo |
string | yes | The organization and repo of the workflow. E. g: “humanitec/example-repo” |
ref |
string | yes | The git branch name |
workflow |
string | yes | The workflow file name |
access_token |
string | yes | The GitHub access token to use when calling the GitHub API |
inputs |
object | no | Optional inputs to provide in the workflow dispatch trigger |
request_uid_input |
string | no | An optional field to set as a request unique identifier. This can help provide idempotency when launching the workflow |
This action returns the following outputs:
Output | Type | Description |
---|---|---|
run_id |
string | The workflow run id |
conclusion |
string | The conclusion status of the completed run from GitHub. This could be “succeeded”, “failed”, “canceled”, etc. Note that the Pipeline step fails if the conclusion is not “succeeded” |
html_url |
string | A URL to the workflow run in the GitHub UI |
Example use:
jobs:
job-1:
steps:
- uses: native://actions/humanitec/github-workflow@v1
id: gitHubWorkflow
with:
repo: myGitHubOrg/myGitHubRepo
ref: main
workflow: "push.yml"
# Read access token from a secret Application value
access_token: "${{ app.values.github-token }}"
- uses: native://actions/humanitec/log@v1
with:
# Pick up the "conclusion" output provided by the github-workflow action
message: "Conclusion: ${{ steps.gitHubWorkflow.outputs.conclusion }}"
actions/humanitec/gitlab-pipeline@v1
This action triggers a GitLab Pipeline execution and waits until it completes or the Humanitec Pipeline Job times out. The inputs define which GitLab project and branch to trigger the Pipeline in, the variables, and the token to run with.
Input | Type | Required | Description |
---|---|---|---|
project_id |
string | yes | The ID or URL-encoded path of the project |
ref |
string | yes | The git branch or tag to run the Pipeline |
private_token |
string | yes | The GitLab access token to use when calling the GitLab API |
variables |
array | no | An array of objects describing the inputs to the Pipeline as “key”, “variable_type”, and “value” according to this GitLab API endpoint |
This action executes the GitLab Pipeline until it reaches a terminal state.
This action returns the following outputs:
Output | Type | Description |
---|---|---|
pipeline_id |
string | The Pipeline execution id |
web_url |
string | A URL to the Pipeline execution in the GitLab UI |
Example use:
jobs:
job-1:
steps:
- uses: native://actions/humanitec/gitlab-pipeline@v1
id: gitLabPipeline
with:
project_id: "my-project/my-pipeline"
ref: main
# Read access token from a secret Application value
private_token: "${{ app.values.gitlab-token }}"
variables:
- key: MY_VAR_1
value: true
variable_type: file
- key: MY_VAR_2
value: "test"
variable_type: env_var
- uses: native://actions/humanitec/log@v1
with:
# Pick up the "pipeline_id" output provided by the gitlab-pipeline action
message: "Pipeline execution ID: ${{ steps.gitLabPipeline.outputs.pipeline_id }}"
Deltas and Deployments
actions/humanitec/apply@v1
This action produces a new Deployment Set by applying a Delta to the current state of an Environment. This Deployment Set can then be deployed or cloned to another Environment.
Input | Type | Required | Description |
---|---|---|---|
env_id |
string | yes | The Humanitec Environment id to apply the Delta to |
delta_id |
string | yes | The delta_id to apply. This Delta can be from the current Environment or a different Environment |
This action will provide a Deployment Set as an output.
Output | Type | Description |
---|---|---|
set_id |
string | The Deployment Set id |
Example use:
on:
pipeline_call:
inputs:
delta_id:
type: string
required: true
jobs:
job-1:
steps:
- uses: native://actions/humanitec/apply@v1
id: applyDelta
with:
env_id: development
delta_id: ${{ inputs.delta_id }}
- uses: native://actions/humanitec/log@v1
with:
# Pick up the "set_id" output provided by the github-workflow action
message: "Deployment Set ID: ${{ steps.applyDelta.outputs.set_id }}"
actions/humanitec/approve@v1
This action blocks the Pipeline execution until a user with deployment permissions on the target Environment has approved or denied the approval resource through the UI or API . The timeout is that of the surrounding Job or entire Pipeline.
Input | Type | Required | Description |
---|---|---|---|
env_id |
string | yes | The Humanitec Environment id to validate the approval against |
message |
string | yes | The approval message to display in the approval request |
Example use:
on:
pipeline_call:
inputs:
target_env_id:
type: string
required: true
jobs:
job-1:
steps:
- uses: native://actions/humanitec/approve@v1
id: approve
with:
env_id: development
message: "Please approve deployment to ${{ inputs.target_env_id }} environment"
actions/humanitec/clone@v1
This action clones a Deployment Set from one Environment to another, producing both a new Deployment Set and a Delta. The Deployment Set can then be deployed into the target Environment.
Input | Type | Required | Description |
---|---|---|---|
from_env_id |
string | yes | The Environment id to clone the Deployment Set from |
to_env_id |
string | yes | The Environment id where the Delta and Set will be produced |
from_deployment_id |
string | no | The specific Deployment id to clone. If this input is not provided, it will clone the latest Deployment in the from_env |
include |
string | no | A regular expression which will be matched against the Workloads in the resulting Delta. Non-matching Workloads are removed from the Delta |
exclude |
string | no | A regular expression which will be matched against the Workloads in the resulting Delta. Matching Workloads are removed from the Delta. Takes precedence over include if both expressions match a Workload |
This action returns the following outputs:
Output | Type | Description |
---|---|---|
set_id |
string | The resulting Deployment Set Id |
delta_id |
string | The resulting Delta id |
Example use:
on:
pipeline_call:
inputs:
from_env_id:
type: string
required: true
to_env_id:
type: string
required: true
jobs:
job-1:
steps:
- uses: native://actions/humanitec/clone@v1
id: clone
with:
from_env_id: ${{ inputs.from_env_id }}
to_env_id: ${{ inputs.to_env_id }}
# Exclude all Workloads containg the term "demo" from the resulting Delta
exclude: "demo"
actions/humanitec/create-delta@v1
The create-delta action can construct a new Delta from a list of Platform Orchestrator workload
artefacts or container images
. The workload artefacts will all be converted into new or updated Workloads within a Humanitec Delta. The container images
will be matched against existing Workloads and be processed as updated if the image repository matches.
This step is best used together with an “
artefact
” trigger event which can produce workload_artefacts
and images
in the correct format.
Input | Type | Required | Description |
---|---|---|---|
env_id |
string | yes | The Environment id to create the Delta in |
name |
string | no | An optional name to apply to the Delta |
workload_artefacts |
[]string | no | The list of workload artefact versions to add to the delta. This input is compatible with the workload_artefacts output of the artefact trigger |
images |
[]string | no | The list of container images to match with existing workloads and process as updates. These images do not have to be registered in the artefact API. This input is compatible with the container_artefacts output of the artefact trigger |
This action provides a Deployment Delta as an output.
Output | Type | Description |
---|---|---|
delta_id |
string | The resulting Delta id |
Example use showing the chaining of the create-delta
action with the subsequent use of
apply
(to create a Set from the Delta) and
deploy
(to deploy the Set):
name: Example Artefact Pipeline
on:
artefact:
type: container
run-as: "s-12345678-abcd-1234-efab-0987654321ba"
include:
- "myimage"
jobs:
job-1:
steps:
- uses: native://actions/humanitec/log@v1
with:
message: "Image versions: ${{ toJson(inputs.container_artefacts) }}"
- uses: native://actions/humanitec/create-delta@v1
id: create-delta
with:
env_id: development
images: ${{ inputs.container_artefacts }}
- uses: native://actions/humanitec/apply@v1
id: apply
with:
env_id: development
delta_id: ${{ steps.create-delta.outputs.delta_id }}
- uses: native://actions/humanitec/deploy@v1
with:
env_id: development
set_id: ${{ steps.apply.outputs.set_id }}
This Pipeline would be triggered by a notification using the humctl
CLI:
humctl create artefact-version --type container \
--name "myimage" \
--version "latest" \
--commit "0b41a3f4b17fc84ec2ba045ebac9796ad07dc123" \
--ref "refs/head/main"
actions/humanitec/deploy@v1
The deploy
action is one of the most used Steps in Pipelines. This action deploys a Deployment Set to a target Environment. The Deployment Set can be produced from an
apply
action, a Pipeline input, or may be a Set id that was already deployed in the past. The
value set version
can also be specified and will default to the latest value set in the Environment if not specified.
Input | Type | Required | Description |
---|---|---|---|
env_id |
string | yes | The Environment id to deploy to |
set_id |
string | yes | The Deployment Set to deploy to the Environment |
value_set_version_id |
string | no | An optional value set version to deploy with. This defaults to the latest version but can be specified if the intention is to rollback to a previous version of the value set |
comment |
string | no | An optional comment to apply to the Deployment |
This action returns the following outputs:
Output | Type | Description |
---|---|---|
deployment_id |
string | The resulting Deployment id |
set_id |
string | The Deployment Set that was used in the Deployment |
value_set_version_id |
string | The value set version that was used in the Deployment |
status |
string | The status of the Deployment. This may be “failed” or “succeeded”. The step automatically fails if the status is “failed” |
Example use for an
Artefact Automation Pipeline
: see the
create-delta
action.
Example use for an API-triggered Pipeline :
name: Example API-triggered deploy Pipeline
on:
pipeline_call:
inputs:
set_id:
type: string
required: true
description: The Deployment Set id to deploy
env_id:
type: string
required: true
description: The Environment id to deploy into
jobs:
job-1:
steps:
- uses: native://actions/humanitec/deploy@v1
id: deploy
with:
set_id: ${{ inputs.set_id }}
env_id: ${{ inputs.env_id }}
- uses: native://actions/humanitec/log@v1
with:
message: "The resulting Deployment id is ${{ steps.deploy.outputs.deployment_id }}"
Other
actions/humanitec/log@v1
Writes a log message to the Pipeline logs. This can be useful for debugging or auditing Pipeline execution.
Input | Type | Required | Description |
---|---|---|---|
message |
string | yes | The message to publish. It supports expressions |
level |
string | no | Optional log level for the output. Supported values are INFO (default), DEBUG, and ERROR |
This action returns no outputs.
Most examples for the other actions on this page show the usage of the “log” action. Use this snippet as quick guidance:
name: My logging Pipeline
on:
pipeline_call:
inputs:
my_input:
type: string
required: true
jobs:
job-1:
steps:
- uses: native://actions/humanitec/log@v1
with:
message: "I received: ${{ inputs.my_input }}"
level: DEBUG
actions/humanitec/fail@v1
Fails the Pipeline Step and writes a log message. This is similar to the log
action but will always write the message at ERROR
level.
Input | Type | Required | Description |
---|---|---|---|
message |
string | yes | The message to publish. It supports expressions |
This action returns no outputs.
Example use:
name: Deployment with Notifications
on:
deployment_request: {}
...
jobs:
deploy:
...
notify:
needs: ["deploy"]
steps:
# Fail the pipeline if the initial deployment failed
- name: Fail if deploy failed
if: ${{ needs.deploy.status == 'failed' }}
uses: native://actions/humanitec/fail@v1
with:
message: Deployment failed.
actions/humanitec/wait-for-readiness@v1
Waits until all Workloads in an Environment are in a “ready” state, otherwise fails the Pipeline Step after a timeout.
Input | Type | Required | Description |
---|---|---|---|
env_id |
string | yes | The Environment id to check |
include_workloads |
string | no | An optional regular expression indicating which Workloads in the Deployment Set should be waited for |
exclude_workloads |
string | no | An optional regular expression indicating which Workloads to ignore in the Deployment Set |
timeout_minutes |
integer | no | The timeout in minutes. Defaults to two minutes if not provided |
This action returns no outputs.
Example use:
name: Deployment with waiting
on:
deployment_request: {}
...
jobs:
deploy:
...
wait:
needs: ["deploy"]
steps:
- name: "Wait for Workload readiness"
id: wait-for-workload-readiness
uses: native://actions/humanitec/wait-for-readiness@v1
with:
env_id: ${{ inputs.environment }}