Pipelines

Kind

Capability

Wait For Workloads Readiness Or Fail

When the Platform Orchestrator deploys changes into an Environment, the Deployment status indicates whether it successfully provisioned associated resources and configured the Workloads. It does not necessarily imply that the Workloads are healthy or that the desired functionality is available to end users. The Pipeline will also be successful in scenario where the Workload will never be Ready, for example when the container image doesn’t exist (ImagePullBackOff), or when an admission controller is blocking the deployment in the Kubernetes cluster, etc.

Humanitec Pipelines can be used to wait for the readiness of the Worklaods deployed in Kubernetes, and fail the Pipeline if the previous step timed out.

This Pipeline definition shows how to accomplish this.

Note: the Deployment status on the Deployment in the Platform Orchestrator will still be Successful.

When the Pipeline is in Failed status, humctl score deploy --wait or humctl deploy --wait will fail. Then to get the associated errors, you can catch the details of errors by combining the result of:

  • humctl get deployment-error
  • humctl api get /orgs/${HUMANITEC_ORG}/apps/${APP}/envs/${ENV}/runtime

pipeline.yaml ( view on GitHub ) :

name: Wait for Workloads readiness or fail

# This pipeline is a deployment request pipeline and runs for any deploy or re-deploy.
on:
  deployment_request: {}

# This pipeline needs permissions to deploy to our development environments. We could add staging and production here too.
permissions:
  application: developer
  env-types:
    development: deployer

# Because this pipeline runs tests, we're going to use concurrency controls to ensure only one deploy and test cycle is running at a time against the target environment.
concurrency:
  group: "${{ pipeline.id }}-${{ pipeline.app.id }}-${{ inputs.env_id }}"

jobs:
  deploy:
    steps:
    # Taken from default Pipeline definition.
    # If there is no existing deployment set in the request, create one by applying the delta to the target environment.
    - if: ${{ ! inputs.set_id }}
      name: Create Deployment Set
      id: create-deployment-set
      uses: actions/humanitec/apply@v1
      with:
        delta_id: ${{ inputs.delta_id }}
        env_id: ${{ inputs.env_id }}

    # Taken from default Pipeline definition.
    # Finally deploy the set to the target environment with a custom message and optional value set. 
    - name: Deploy Set To Environment
      uses: actions/humanitec/deploy@v1
      with:
        set_id: ${{ inputs.set_id || steps.create-deployment-set.outputs.set_id }}
        value_set_version_id: ${{ inputs.value_set_version_id }}
        env_id: ${{ inputs.env_id }}
        message: ${{ inputs.comment }}

    # Waits until all Workloads in an Environment are in a “ready” state, otherwise fails the Pipeline Step after a timeout.
    - name: Wait for Workloads readiness
      continue-on-error: true # Optional, if you want to have another step after this one in case of failure to write a custom message, send a message in Slack, etc.
      id: wait-for-workloads-readiness
      uses: actions/humanitec/wait-for-readiness@v1
      with:
        env_id: ${{ inputs.env_id }}
        timeout_minutes: 2

    # (Optional) Fails the Pipeline Step and writes a custom error message. It's an example that you can adapt and replace by other actions like send a message in Slack, etc.
    - if: ${{ steps.wait-for-workloads-readiness.status == 'failed' }}
      name: Fail if Workloads readiness failed
      uses: actions/humanitec/fail@v1
      with:
        message: Workloads readiness failed, check the Runtime errors.

Top