Recap: Weekend Out Exercise

Recap: Weekend Out Exercise#

Let’s revisit last week’s Weekend Out exercise to deepen our understanding of GitHub workflows in practice.

What Actually Happened?#

Think back to the exercise where multiple people (you, Alice, Bob, and Carol) were collaborating on a packing list. Some unexpected things happened automatically - let’s understand why!

Key Questions

  • What exactly was going on in the Weekend-Out repository?

  • How did a merge conflict occur automatically?

  • What triggered the workflows?

  • Who (or what) made commits as “Carol[bot]” and “Alice[bot]”?

  • Why did two drone lists end up in the main branch?

Hint

Take another look at the .github/workflows/ directory in the Weekend-Out repository.

Three workflow files were silently working in the background:

  • auto-commit-blanket.yml

  • carols_drone_and_alice.yml

  • carols_issue.yml

Workflow 1: Auto-Commit Blanket

name: Auto Commit Blanket
on:
  create

jobs:
  auto-commit-on-blanket-branch:
    if: ${{ contains(github.ref, 'essentials')}}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          ref: main
      - name: Make changes to packing_list.md
        run: |
          echo "- [ ] extrawarm blanket" >> packing_list.md
          git config --global user.name 'Carol[bot]'
          git config --global user.email 'Carol[bot]@wonderland.com'
          git add packing_list.md
          git commit -m "Adding warm blanket"
          git push origin main

Questions:

  • What triggers this workflow? The create event (when a branch is created)

  • What’s the condition? Only runs if branch name contains ‘essentials’

  • What does it do? Commits directly to main (not the feature branch!)

  • Why does this cause a conflict? You’re editing the same line in two places

Workflow 2: Carol’s Drone and Alice

name: Auto Commit Blanket
on:
  pull_request:
    types:
      - opened

jobs:
  adding-list:
    if: ${{ contains(github.head_ref, 'restruct') }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          ref: main
      - name: Adding drone to packing_list.md
        run: |
          echo "- [ ] drone" > Carols_drone_list.md
          echo "- [ ] extra battery" >> Carols_drone_list.md
          git config --global user.name 'Alice[bot]'
          git config --global user.email 'Alice[bot]@wonderland.com'
          git add Carols_drone_list.md
          git commit -m "Adding Carols drone list"
          git push origin main

Questions:

  • What triggers this workflow? Opening a pull request

  • What’s the condition? PR branch name contains ‘restruct’

  • What does it do? Creates Carols_drone_list.md and pushes to main

  • Why do two drone lists appear? Alice[bot] commits while you’re working on your PR

Workflow 3: Carol’s Issue Comment

name: Carols Issue
on:
  issues:
    types:
      - opened

jobs:
  carols_issue:
    if: ${{ contains(github.event.issue.title, 'restruct')}}
    runs-on: ubuntu-latest
    steps:
      - name: Carol comments
        run: |
          echo -e "**Carol** wants to create a dedicated list..." > msg
          export msg=$(cat msg)
          gh issue comment ${{ env.EVENT }} --body "$msg" \
            --repo ${{ env.OWNER }}/${{ env.REPO }}

Questions:

  • What triggers this workflow? Opening an issue

  • What’s the condition? Issue title contains ‘restruct’

  • What does it do? Posts a comment as Carol[bot]

  • Purpose? Simulates team collaboration and provides instructions

Understanding the Chaos#

The Merge Conflict

  1. You create feature/essentials branch

  2. Workflow 1 immediately commits to main (adds “extrawarm blanket”)

  3. You locally add blankets to the feature branch

  4. When you merge: conflict! (same line modified in both places)

The Duplicate Lists

  1. You create an issue with ‘restruct’ in title

  2. You create a PR from a branch with ‘restruct’ in name

  3. Workflow 2 triggers and commits Carols_drone_list.md to main

  4. You also create a drone list and merge your PR

  5. Result: Two drone lists in main!

Key Takeaways#

Workflows Run Independently

Workflows are triggered by events, not by human intention. They run automatically and can make changes to your repository without your direct involvement.

Branch Protection Matters

Allowing direct commits to main (as these workflows do) can lead to conflicts and unexpected state. Branch protection rules help prevent this.

Always Pull Before Push

The workflows committed to main while you were working. Always pull the latest changes before merging to avoid conflicts.

Coordination is Critical

In a real team, workflows should be documented and coordinated. The “chaos” was intentional for learning, but in production, workflows should be predictable.

Reflection Questions#

Before we move on to GitLab pipelines, consider:

  1. Event-Driven Architecture: How do the on: triggers demonstrate event-driven automation?

  2. Conditional Execution: How do the if: conditions control when jobs run?

  3. Context Access: How do workflows access repository information (github.ref, github.head_ref, github.event)?

  4. Permissions: What permissions did these workflows need and why?

  5. Bot Commits: How did the workflows impersonate users (Carol[bot], Alice[bot])?

  6. Real-World Application: How would you use similar patterns (without the chaos) in a real project?

Content