🚀 Day 05: Outputs in GitHub Actions

Welcome back to Day 05 of our GitHub Actions Journey 👋.
So far, we’ve learned about workflows, jobs, events, triggers, and artifacts.

Today, we’re tackling something super powerful: Outputs.

Think of outputs as a way for jobs and steps to “talk” to each other.
Without outputs, jobs would be isolated islands. With outputs, they become a connected pipeline 🌉.

---

🎯 What Are Outputs?

Outputs in GitHub Actions are just values generated in one job (or step) that can be used later in another job (or step).

👉 Example:

• Job 1 builds an app and generates a build ID.

• Job 2 takes that build ID and uses it during deployment.

It’s like passing notes in class 📒 — one person writes, another person reads.

---

🛠 Example 1: Passing a Build ID Between Jobs

We’ll generate a unique build ID in the build job and then reuse it in the deploy job.

name: Day 05 – Outputs Demo

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.generate_id.outputs.build_id }}
    steps:
      - name: Generate Build ID
        id: generate_id
        run: echo "build_id=build-$(date +%s)" >> $GITHUB_OUTPUT

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Use Build ID from Build Job
        run: echo "Deploying with ID: ${{ needs.build.outputs.build_id }}"

🔍 Explanation:

• In the build job, we create a unique ID (build-<timestamp>).

• We store it as an output with $GITHUB_OUTPUT.

• In the deploy job, we access it with:

    ${{ needs.build.outputs.build_id }}
  

---

🛠 Example 2: Passing Step Output Inside the Same Job

Outputs also work at the step level inside a single job.

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
      - name: Generate Message
        id: hello_step
        run: echo "msg=Hello from Step 1" >> $GITHUB_OUTPUT

      - name: Use Message
        run: echo "The message is: ${{ steps.hello_step.outputs.msg }}"

👉 Here, Step 1 creates a message and Step 2 prints it.
This is super useful when step 2 depends on data from step 1.

---

🛠 Example 3: Real-World Use Case – Testing & Deploying

Imagine:

• Job 1 runs tests and generates a summary (✅ All tests passed).

• Job 2 deploys only if Job 1 passes, and also uses the test summary.

jobs:
  test:
    runs-on: ubuntu-latest
    outputs:
      summary: ${{ steps.test_summary.outputs.summary }}
    steps:
      - name: Run Tests
        run: echo "summary=✅ All tests passed" >> $GITHUB_OUTPUT
        id: test_summary

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Deploy App
        run: echo "Deploying app... Test status: ${{ needs.test.outputs.summary }}"

This way, your deploy logs will carry the test results along with them.
That’s real DevOps magic ⚡.

---

📂 Try It Yourself

👉 You can find today’s workflow here:
📌 Day 05 Outputs Workflow

And the documentation here:
📌 Day 05 README

Steps:

1. Fork the repo.

2. Navigate to the Actions tab.

3. Run the Day 05 – Outputs Demo workflow.

4. Check the logs to see outputs flowing between jobs 🎉.

---

🎯 Summary

• Outputs = passing data between steps and jobs.

• You learned:

  • How to set outputs in steps ($GITHUB_OUTPUT).

  • How to share outputs between jobs (needs.job_id.outputs.var).

  • Practical real-world examples: build IDs, messages, test results.

This is how you start building pipelines that actually communicate 🛠️.

---

🔗 Follow My Journey

I’m documenting everything in public! You can follow along here:

• 📝 Terraform Learning Journey

• ⚙️ GitHub Actions Learning Repo

• 🐦 Follow me on X for daily updates

---

🔥 That’s a wrap for Day 05. Tomorrow, we’ll go even deeper!