Using Marketplace Actions

Using Marketplace Actions

Actions package common tasks such as checkout, tool installation, authentication, caching, and deployment. Marketplace discovery is convenient, but each third-party action is code that runs with the job's token, secrets, workspace, and network access.

Core ideas

• JavaScript, Docker container, and composite actions have different runtime and portability characteristics.
• The uses syntax identifies an owner, repository, and ref; local actions use a relative path.
• A full commit SHA is immutable. A moving tag such as v4 is convenient but can change.
• Verified creator status confirms publisher identity, not that every behavior is risk-free.

How it works

Before adopting an action, review its source, release history, maintenance activity, permissions, inputs, outputs, and transitive dependencies. Pin third-party actions to a reviewed SHA and use an update process that proposes deliberate upgrades.

Configuration example

permissions:
  contents: read

jobs:
  package:
    runs-on: ubuntu-latest
    steps:
      - name: Check out source
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
      - name: Run local composite action
        uses: ./.github/actions/verify
        with:
          strict: "true"

Read the example from top to bottom: the trigger creates a run, the job requests a runner, and each step receives only the context configured for it. Adapt names, versions, permissions, and commands to the repository rather than copying production credentials or policies blindly.

Production guidance

• Prefer maintained official actions when they meet the requirement.
• Document why each third-party action is trusted and which version was reviewed.
• Remove unused action permissions and never pass the complete secrets context to an action.

The chapter quiz follows this lesson and checks both the vocabulary and the operational decisions behind the configuration.