Skip to main content
Actions are the reusable automation building blocks used inside GitHub Workflows. They encapsulate a single task—such as checking out source code, setting up a runtime, or publishing artifacts—and can be authored by you, by your organization, or by the broader community. Sharing actions enables consistent, composable automation across repositories and teams. You can discover and evaluate actions on the GitHub Marketplace:
A screenshot of an "Actions" page divided into "GitHub-Verified Actions" and "Third-Party/Community Actions" sections. Each section shows example action cards like "Setup Java JDK," "Authenticate to Google Cloud," and "Deploy to GitHub Pages."
Actions in the Marketplace fall into two broad categories:
  • GitHub-verified actions: maintained or verified by GitHub; carry a verified badge.
  • Community (third-party) actions: created and maintained by individuals or organizations.
Always review an action’s source repository and the permissions it requests before adding it to production workflows—particularly any actions that will run against private repositories or that may receive secrets. Inspecting the action’s code helps prevent accidental leakage of secrets or sensitive data.
Before adding an action, verify its source and the permissions it requires. This minimizes risk of secret exposure and unexpected side effects in your workflows.

​
How to reference an action in your workflow

Every action published in the Marketplace exposes a uses reference that you include in a job step. You can pin an action to a specific:
  • Tag (recommended for controlled versioning)
  • Branch (tracks latest on that branch)
  • Commit SHA (immutable and most reproducible)
The differences are summarized below.
Referencing a branch (for example, @main) means the action may change without any changes to your workflow. This can introduce breaking behavior if the upstream branch receives incompatible updates.
Examples of referencing an action in a workflow:
SHAs are immutable, making them the most dependable choice for reproducible workflows. Many teams adopt a practical compromise: pin to a stable major tag (for example @v3) or a specific release tag (for example @v3.6.0) and then periodically update to a new tag or SHA after validating the action in a test environment.

​
Best practices

  • Pin actions to a tag or SHA to avoid unexpected changes in CI.
  • Prefer actions from verified authors or well-known maintainers.
  • Review action source code (or vendor internal copies) for how secrets and repository data are handled.
  • Use least-privilege permissions for workflow tokens and secrets; avoid granting excessive access to third-party actions.
Additional security considerations for actions and workflows will be covered later in this course.

Watch Video