Ensure stable and predictable execution of your GitHub workflows by versioning your custom actions. In this guide, we’ll cover three methods to specify exact action releases: tags, branches, and commit SHAs.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
1. Versioning with Tags
Tags are the most common approach to label and organize GitHub Action releases. They support both flexible version ranges and precise version pins.| Tag Type | Purpose | Example |
|---|---|---|
| Major version | Significant or breaking changes | uses: actions/checkout@v3 |
| Pre-release (beta) | Beta releases for testing before GA | uses: actions/checkout@v3-beta |
| Semantic versioning | Precise MAJOR.MINOR.PATCH tags | uses: actions/checkout@v3.6.0 |
Using Semantic Versioning ensures clear communication of changes and consistent release management.
2. Referencing a Branch
Referencing a branch name (e.g.,main or master) always pulls the latest action code from that branch. While convenient for continuous updates, this approach can introduce unexpected breaking changes.
Pinning to a branch like
main can lead to non-deterministic builds if the branch receives breaking changes.3. Pinning to a Commit SHA
Commit SHAs guarantee immutability by referencing a specific commit. This is the most reliable method for ensuring your workflow uses exactly the code you intend.Commit SHAs are tamper-proof and cannot be moved or deleted, providing maximum stability.
Summary
Choosing the right versioning strategy depends on your needs:- Tags: Best balance between flexibility and stability.
- Branches: Ideal for continuous updates, but risk instability.
- Commit SHAs: Maximum reliability with immutable references.