Workflow Outputs

In this section, you will find: details about Workflow outputs.

Outputs

You can declare outputs data only in reusable Workflows. This enables the transfer of information between Workflows, Actions, or Plugins. Output data can be declared either in a Step or directly in the Workflow. Each method serves a specific purpose, but both adhere to the same syntax.

Workflow inputs
inputs:
   - type: text
     name: text_input
     label: "Type some text:"
   - type: bool
     name: boolean_input
     label: "Do you want to run optional job?"
computed-inputs:
  computed_input_name: "{{ text_input_name | upper }}"
outputs:
  uppercase_text_output: "{{computed_input_name | encrypt }}" 

The output defined in the previous example can be accessed by other jobs and steps in the workflow executed later using a Jinja expression.

Consider the following job that will use the output:

schema-version: v1
kind: workflow
metadata: ...
spec:
  jobs:
    - name: my_job
      label: My job
      steps:
        - action: my-studio/my-action@1
          name: my_action
          inputs:
            some_text: "Hello!"

The Jinja expression to use the output should follow this syntax:

{{ outputs.<nome-do-job>.<nome-do-step>.<nome-do-output> }}

Example:

{{ outputs.my_job.my_action.some_text_upper }}

tip

Workflow outputs function similarly to computed-inputs. To learn more about how to use Workflow Outputs, see the computed-inputs page.

Generating outputs in `run` steps

In reusable Workflows, you can also generate outputs in run steps. In the script field of your run step, use the following syntax:

Output syntax in a 'run' step.
echo output_name=output_value >> $STK_OUTPUTS

Examples:

Set a value for the output, following the example below:

echo environment_name='development' >> $STK_OUTPUTS

Use other variables and apply Jinja filters. Consider using a variable from your Workflow, as in the example below:

echo "branch_lower={{ branch | lower }}" >> $STK_OUTPUTS

See an example of usage:

kind: workflow
schema-version: v1
metadata:
  name: lint-test-notify
  version: 1.0.0
  display-name: Lint, Test and Notify
  description: Example of outputs in a scenario of test execution, linting, and application notification.
spec:
  type: reusable
  label: Lint + Test + Notify
  targets:
    - app
    - infra
  docs:
    pt_br: docs/pt-br.md
    en_us: docs/en-us.md
  inputs:
    - type: text
      label: Branch name
      name: branch
      default: feature/NEW-FEATURE
    - type: int
      label: Minimum coverage (0-100)
      name: coverage_threshold
      default: 80
  jobs:
    - id: prepare
      label: Collect context
      steps:
        - id: collect
          type: run
          label: Collect changed files and normalize branch
          script: |
            # Defining a simple output (static/simulated value)
            echo "changed_files=5" >> $STK_OUTPUTS

            # Using a variable with Jinja filter (branch in lowercase)
            echo "branch_lower={{ branch | lower }}" >> $STK_OUTPUTS

    - id: test
      label: Run tests
      depends-on:
        - prepare
      # Using an output from another job/step in the when condition
      when: "{{ outputs.prepare.collect.changed_files | int > 0 }}"
      steps:
        - id: run_tests
          type: run
          label: Run tests and register status
          script: |
            THRESHOLD="{{ coverage_threshold }}"
            # Simulating calculated coverage
            COVERAGE=82

            if [ "$COVERAGE" -ge "$THRESHOLD" ]; then
              echo "test_status=passed" >> $STK_OUTPUTS
            else
              echo "test_status=failed" >> $STK_OUTPUTS
            fi

    - id: notify
      label: Notify success
      depends-on:
        - test
      # Condition based on another output generated in the 'test' job
      when: "{{ outputs.test.run_tests.test_status == 'passed' }}"
      steps:
        - id: send_message
          type: run
          label: Send notification
          script: |
            echo "message=Build OK on branch {{ outputs.prepare.collect.branch_lower }}" >> $STK_OUTPUTS
            echo "notified=true" >> $STK_OUTPUTS

tip

Use output names in snake_case and without spaces.
Avoid exposing secrets via outputs. Prefer connections and secure variables.
Keep scripts idempotent and fast. Return only what is necessary in $STK_OUTPUTS.
Always reference outputs with the syntax: {{ outputs.<job_id>.<step_id>.<output_name> }}
Use the same syntax for output values in Shell-type Actions.

Outputs

Generating outputs in run steps

Generating outputs in `run` steps