---

What Are GitHub Actions Workflows?

GitHub Actions is GitHub’s built-in platform for automating development processes such as building, testing, and deploying applications. It supports both continuous integration (CI) and continuous delivery/deployment (CD) by allowing developers to create automated pipelines directly inside their repositories.

A workflow is an automation file—written in YAML—that defines a sequence of tasks (called actions) that should run when specific events occur. These workflow files live inside the repository and execute whenever a trigger fires, such as a new pull request, a push to a branch, a scheduled time, or a manual execution through the GitHub interface.

Workflows are stored in the repository at .github/workflows/, and you can have as many as needed. Each workflow can serve a different purpose: one might run unit tests on every pull request, while another deploys your application when a release is created.

---

Core Concepts of GitHub Actions Workflows

1. Workflow Triggers

Triggers determine when a workflow runs. GitHub supports four major trigger categories:

1. Repository Events – e.g., pushes, pull requests, new releases.
2. External Events – triggered via the repository_dispatch API from outside GitHub.
3. Scheduled Events – automated cron-style schedules.
4. Manual Runs – triggered directly through the GitHub UI.

Once a trigger fires, GitHub launches the workflow and executes the defined jobs and steps.

---

How a Workflow Runs (Behind the Scenes)

Here’s a simplified version of what happens when an event starts a workflow:

1. An event occurs and is associated with a commit SHA and reference (branch or tag).
2. GitHub looks inside .github/workflows/ for workflow files that match that event.
3. If a workflow is configured for that trigger, GitHub runs the version of the workflow tied to that commit SHA.
4. Environment variables like GITHUB_REF and GITHUB_SHA are populated automatically.
5. The workflow then proceeds to run its defined jobs.

---

Workflow Jobs and Concurrency

A workflow is composed of one or more jobs, and each job contains a sequence of steps.

Key job behaviors:

• Jobs run in parallel by default.
• You can force jobs to run sequentially using the needs: keyword.
• You can restrict execution using concurrency groups (jobs.<id>.concurrency).
  This ensures that only one workflow in that group runs at a time.

If a workflow in the same concurrency group is already running, new ones will wait or cancel depending on settings.

---

Workflow Syntax and Structure (YAML)

GitHub workflows use YAML. The files must be placed in:

.github/workflows/

Below are the core elements.

---

1. name

Sets the workflow’s display name in GitHub Actions.

Example:

name: demo-github-actions-workflow

If omitted, GitHub uses the file path as the default name.

---

2. on (Triggers)

Defines the events that activate the workflow.

Examples:

Trigger on any push:

on: push

Trigger on push or fork:

on: [push, fork]

Trigger on branch protection rule updates:

on:
  branch_protection_rule:
    types: [edited, created]

Trigger only for PR assignments on certain branches:

on:
  pull_request:
    types: [assigned]
    branches:
      - "demo-branch/**"

Trigger when only Python files change:

on:
  push:
    paths:
      - "**.py"

---

3. defaults

Defines default settings for all run: commands.

Example:

defaults:
  run:
    shell: bash
    working-directory: demo-workflow-scripts

---

4. jobs

The heart of the workflow—defines what tasks the workflow performs.

Each job needs a unique identifier.

Example:

jobs:
  first_demo_job:
    name: The first demo job
  second_demo_job:
    name: The second demo job

Steps inside a job:

jobs:
  first_demo_job:
    steps:
      - name: Display variables
        env:
          VAR1: "This is"
          VAR2: "a demo of"
          VAR3: "GitHub Actions"
        run: |
          echo "$VAR1 $VAR2 $VAR3"

---

Workflow Commands

1. Setting Outputs

Allows you to store values and use them later in the workflow.

- name: Set output
  id: setter
  run: echo '::set-output name=msg::hello'

- name: Read output
  run: echo "Output: ${{ steps.setter.outputs.msg }}"

---

2. Logging Errors

Outputs structured error messages to the log.

echo "::error file=demo.js,line=1,col=7,endColumn=9::Missing semicolon"

---

3. Controlling Command Echoing

Turns command logging on or off.

echo "::echo::on"
echo "::echo::off"

---

Quick Guide: Creating Starter Workflows

Starter workflows are templates other users can choose when creating new workflow files.

To create one:

1. Create the .github/workflow-templates/ directory.
2. Add a workflow file, e.g., demo-workflow.yml:

name: Starter Workflow Demo

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Demo
        run: echo "This is a starter workflow"

3. Add the matching metadata file demo-workflow.properties.json:

{
  "name": "Starter Workflow Demo",
  "description": "Demo starter workflow.",
  "iconName": "demo-icon",
  "categories": ["Python"]
}

The metadata helps categorize and display the workflow in GitHub’s starter library.

---

Extending GitHub Actions with Codefresh

While GitHub Actions excels at CI automation, GitOps and Kubernetes-native deployments typically require more advanced tooling. Codefresh complements GitHub Actions by offering features built specifically for modern, cloud-native development, such as:

• Application and environment dashboards
• Git-based deployment management
• Drift detection and environment control
• Kubernetes topology and visibility
• Full GitOps workflow powered by Argo (Workflows, Events, CD, Rollouts)

By combining GitHub Actions (for CI) with Codefresh (for GitOps/CD), teams get a complete and scalable build–deploy pipeline.

---