Automating Your Release Pipeline with GitHub Actions

Why Custom Actions

When I built the Sentry Release GitHub Action, it was because the existing solutions did not quite fit our workflow. We needed something that worked with self-hosted Sentry instances and integrated cleanly with semantic-release.

Anatomy of a GitHub Action

A GitHub Action at its core is a action.yml manifest plus executable code. The manifest defines inputs, outputs, and runtime configuration.

1name: 'Sentry Release'
2description: 'Create a Sentry release with commits and deploys'
3inputs:
4  version:
5    description: 'Release version'
6    required: true
7  environment:
8    description: 'Deployment environment'
9    required: false
10    default: 'production'
11runs:
12  using: 'node12'
13  main: 'index.js'

Environment Variable Strategy

Sentry needs authentication tokens, org slugs, and project names. Using environment variables keeps the action configuration clean and secrets secure.

Composing Actions

The real power comes from composing multiple actions. Our release pipeline chains semantic-release with Sentry release creation, so every version bump automatically creates a tracked release.

Error Handling

GitHub Actions fail silently by default. Always use core.setFailed() to surface errors clearly, and add retry logic for network-dependent operations like API calls to Sentry.

Lessons Learned

Building a public GitHub Action taught me the importance of minimal dependencies, clear documentation, and comprehensive input validation. The action has been running in production for years across multiple organizations.