Main Branch

Fundamentals first, always

Issue #19

🥊 Main Branch: The One Where Actions Stops Fighting You 🛠️

By Andrea Griffiths • Leer en Español
github-actions environments cron timezone open-source
Listen to article

Hiya friends,

You ever have a tool you rely on every day that just… has rough edges? You know how to work around them, you’ve memorized the workarounds, but they still cost you five minutes every single time.

This week, GitHub Actions smoothed out two of mine.

🚢 What Shipped

Actions: Use environments without creating a deployment

Environments in GitHub Actions are great for managing secrets and variables per stage (staging, production, etc.). The problem? Every time a workflow ran against an environment, it created a deployment. That meant noisy deployment history for workflows that were just borrowing the secret management, not actually deploying anything.

Now you can opt out. Add deployment: false to your environment block in the workflow YAML. This is per job, under jobs.<job_id>.environment:

jobs:
  build:
    environment:
      name: staging
      deployment: false
    steps:
      - run: echo "Using staging secrets, no deployment created"

One caveat: custom deployment protection rules (the GitHub App kind) require an actual deployment object. If you set deployment: false, the job fails immediately.

Actions: Timezone support for scheduled workflows

Scheduled workflows in Actions have always run on UTC. Full stop. If your team is based in Chicago and you wanted a workflow to run at 9am local time, you were doing timezone math in your head every time you touched the cron expression.

That’s done. You can now pass a timezone field with any IANA timezone name alongside your cron schedule.

on:
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: "America/Chicago"

Your pipeline, your timezone. Finally. Caveat: daylight savings rules apply. If the scheduled time lands in a skipped hour during spring forward, Actions runs it at the next valid time.

📖 What I’m Reading

I prompt injected my CONTRIBUTING.md — 50% of PRs are bots by punkpeye (Frank Fiegel)

A maintainer of awesome-mcp-servers started getting flooded with PRs. Volume was up. Quality was gone. So, they hid a prompt injection in their CONTRIBUTING.md to detect which submissions were coming from AI agents. The results were not surprising. The implications are.

Worth your time if: you maintain any open source project, or you’ve noticed the vibe of incoming contributions changing lately.

🔧 What I’m Using

/chronicle improve in GitHub Copilot CLI is experimental and I can’t stop running it. It reviews your coding sessions, finds where you hit friction, and you can prompt it to update your Copilot instructions, so you don’t hit the same walls twice. It found things in mine I didn’t realize I kept doing.

✨ This Week

Mike McQuaid said something that I keep coming back to: job security is dead, career security is what actually matters. You build that by learning, changing, stepping outside your lane.

Then I read the bot PR piece. Half the contributions on a popular open source repo: automated. Maintainers spending their free time sorting through it.

Showing up as an actual human in this work, curious, accountable, present, might be the most underrated skill we have right now. Lean into that!

That’s it, ship fixes, and show up human.

With gratitude, I’ll see you next week,

Andrea

💛 Support

If Main Branch saves you time or teaches you something new, consider supporting it: