Study guide
6.2 Publishing Actions to GitHub Marketplace
GitHub Actions Certification GH-200
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Overview
1.1 Exam Structure, Format & Scoring 1.2 GitHub Actions Architecture & Core Mental Model 1.3 Hands-On Preparation & Exam Day Strategy
2 Chapter 2: Workflow Triggers & Event Architecture
2.1 Webhook & Code Events: push, pull_request, and pull_request_target 2.2 Scheduled & Manual Triggers: schedule, workflow_dispatch, and repository_dispatch 2.3 Release, Issue, and Dynamic Lifecycle Events 2.4 Branch, Tag, and Path Filtering Patterns
3 Chapter 3: Jobs, Matrix Strategies & Execution Control
3.1 Job Anatomy, Step Execution & Job Dependencies (needs) 3.2 Contexts, Expressions & Functions 3.3 Environment Variables & Workflow Commands 3.4 Matrix Strategies & Multi-Platform Builds 3.5 YAML Anchors, Aliases & Merge Keys
4 Chapter 4: Reusable Workflows & Troubleshooting
4.1 Authoring & Calling Reusable Workflows (workflow_call) 4.2 Comparing Reusable Workflows, Composite Actions & Starter Workflows 4.3 Troubleshooting Workflow Runs & Debug Logging 4.4 Concurrency Controls & Status Check Functions
5 Chapter 5: Authoring Custom Actions
5.1 Action Architecture & action.yml Specification 5.2 Authoring Composite Actions 5.3 Building JavaScript Actions 5.4 Building Docker Container Actions
6 Chapter 6: Action Distribution, Marketplace & Advanced Action Types
6.1 Action Versioning, Semantic Releases & Tagging 6.2 Publishing Actions to GitHub Marketplace 6.3 Service Containers & Network Topology 6.4 actions/github-script & Workflow Tooling
7 Chapter 7: Runner Infrastructure & Self-Hosted Runners
7.1 GitHub-Hosted Runners & Larger Runners 7.2 Self-Hosted Runner Setup, Architecture & Communication 7.3 Self-Hosted Runner Security & Ephemeral Runners 7.4 Runner Groups, Labels & Organization Routing
8 Chapter 8: Enterprise Governance, Policies & Environments
8.1 Enterprise & Organization Action Policies 8.2 Environments, Protection Rules & Deployment Approvals 8.3 Repository Rulesets, Required Status Checks & Governance 8.4 Usage Limits, Billing Multipliers & Usage Metrics
9 Chapter 9: Secrets, Permissions & OIDC Cloud Authentication
9.1 Encrypted Secrets Architecture & Scopes 9.2 GITHUB_TOKEN & Least Privilege Configuration 9.3 OpenID Connect (OIDC) & Workload Identity Federation 9.4 Script Injection Prevention & Secure Workflow Patterns
10 Chapter 10: Supply Chain Hardening & Performance Optimization
10.1 Supply Chain Hardening: SHA Pinning, Dependabot & Artifact Attestations 10.2 Caching Dependencies with `actions/cache` 10.3 Artifacts Management & Job Handoff 10.4 Workflow Performance, Cost Optimization & Architecture Review
6.2 Publishing Actions to GitHub Marketplace
Key Takeaways Explain This Topic AI
Publishing an action to the GitHub Marketplace requires a public repository, an action.yml file located strictly in the root directory, a globally unique marketplace name, a primary category, and a tagged release.
Actions located in repository subdirectories cannot be published directly to GitHub Marketplace; they must reside at the root directory of their own dedicated repository to be indexed.
The Verified Creator badge (blue checkmark) is awarded exclusively to organizations verified by GitHub that maintain verified domains and enforce two-factor authentication (2FA).
Action metadata in action.yml must specify valid name , description , author , and branding ( icon from the Feather icon set and a supported color ).
Security vulnerabilities in published actions are managed through GitHub Security Advisories (GHSA), allowing maintainers to request CVEs and coordinate remediation while avoiding sudden unpublishing that breaks consuming workflows.
Last updated: August 2026
Publishing Actions to GitHub Marketplace
The GitHub Marketplace is the central discovery catalog for reusable actions, workflow apps, and developer integrations. Publishing an action to the Marketplace allows millions of developers across the global GitHub ecosystem to discover, consume, and integrate your tooling into their CI/CD workflows.
However, publishing to the Marketplace is governed by strict repository structure requirements, schema validation rules, security checks, and identity verification programs tested extensively on the GH-200 examination.
1. Marketplace Publishing Prerequisites
Before an action can be listed in the GitHub Marketplace, the repository and its metadata must satisfy five mandatory technical prerequisites: +-----------------------------------------------------------------------------+
- | MARKETPLACE PUBLISHING MANDATORY CHECKLIST |
- | |
- | [1. Public Repository] ─── Private/internal repos cannot be listed |
- | [2. action.yml at Root] ─── Must reside in / (not in subdirectories) |
- | [3. Unique Name] ─── Must not conflict with existing listings |
- | [4. Primary Category] ─── Selected from approved Marketplace topics |
- | [5. Tagged Git Release] ─── Must use a valid SemVer tag (e.g., v1.0.0) |
- +-----------------------------------------------------------------------------+
- Detailed Prerequisite Specifications
Prerequisite Technical Requirement Exam Pitfall / Constraint
Repository Visibility Repository must be Public . Actions in Private or Internal repositories cannot be published to GitHub Marketplace.
File Location Metadata file ( action.yml or action.yaml ) must reside in the root directory of the repository. Actions located in subdirectories (e.g., actions/my-action/action.yml ) cannot be published to Marketplace.
Listing Name Uniqueness The name field in action.yml must be globally unique across all existing GitHub Marketplace actions. Even if your repository name is unique to your account, a duplicate name in action.yml will block publishing.
Category Classification Must select at least one Primary Category (and an optional secondary category). Categories include: API management, Continuous integration, Code quality, Deployment, Security, Testing, Utilities .
Release & Tagging Must create a GitHub Release associated with a valid Git tag. Drafting a release without publishing it or creating an unannotated tag without a release will not list the action.
2. Action Metadata Specification for Marketplace ( action.yml )
To pass marketplace schema validation, action.yml must include complete metadata and a properly formatted branding block. name: 'Super-Linter Advanced'
- author: 'Enterprise DevOps Tooling Team'
- description: 'Automated polyglot code linting and style enforcement across 40+ languages'
# Branding configuration rendered on GitHub Marketplace
branding:
- icon: 'check-circle' # Valid icon from Feather icons (feathericons.com)
- color: 'blue' # Valid color from supported palette
inputs:
github-token:
- description: 'GitHub token for status checks and annotations'
- required: true
- default: '${{ github.token }}'
outputs:
lint-results:
description: 'JSON summary of lint execution status'
runs:
- using: 'node20'
- main: 'dist/index.js'
- Valid Branding Values
Icons: Must match an identifier from the open-source Feather Icons library (e.g., shield , terminal , box , cpu , database , lock , play , check-circle , activity , zap , upload-cloud ).
Colors: Must be one of the eight supported GitHub Marketplace colors: white , yellow , blue , green , orange , red , purple , or gray-dark .
3. The Marketplace Publishing Workflow
Publishing an action is integrated directly into the GitHub Releases interface within the repository. +-----------------------------------------------------------------------------+
- | MARKETPLACE PUBLISHING FLOWCHART |
- | |
- | +---------------------------------------------------------------------+ |
- | | Step 1: Open Repository -> Click 'Releases' -> 'Draft a new release'| |
- | +---------------------------------------------------------------------+ |
- | | |
- | v |
- | +---------------------------------------------------------------------+ |
- | | Step 2: Check box: 'Publish this Action to the GitHub Marketplace' | |
- | +---------------------------------------------------------------------+ |
- | | |
- | v |
- | +---------------------------------------------------------------------+ |
- | | Step 3: Automated Validation checks action.yml, branding, & name | |
- | +---------------------------------------------------------------------+ |
- | | |
- | v |
- | +---------------------------------------------------------------------+ |
- | | Step 4: Select Primary & Secondary Categories | |
- | +---------------------------------------------------------------------+ |
- | | |
- | v |
- | +---------------------------------------------------------------------+ |
- | | Step 5: Choose Tag (e.g., v1.0.0), Title, & click 'Publish Release' | |
- | +---------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------+
Important
Repository Banner: When GitHub detects a valid action.yml in the root of a public repository, a special banner appears at the top of the repository: "Draft a release to publish this Action to the GitHub Marketplace." Clicking this banner automatically pre-selects the marketplace publishing options.
4. The Verified Creator Badge Program
In enterprise environments, security policies often restrict developers to using only first-party GitHub actions or actions from Verified Creators . ┌─────────────────────────────────────┐
- │ actions/checkout │
- │ By GitHub [✔ Verified Creator] │
- │ Category: Utilities │
- └─────────────────────────────────────┘
- Qualifications for Verified Creator Status
A Verified Creator badge (the official blue checkmark icon on Marketplace listings) indicates that GitHub has verified the authenticity of the organization publishing the action.
GitHub Organization Requirement: The action must be published by a GitHub Organization , not an individual personal user account.
Domain Verification: The organization must have completed domain verification via DNS TXT records confirming ownership of the company's official domain name.
Verified Organization Profile: The organization profile must display the verified domain badge publicly.
Two-Factor Authentication (2FA): 2FA must be enforced across all members of the organization.
Partnership / Direct Verification: The organization must be an official GitHub partner or vetted enterprise vendor.
Enterprise Policy Governance
Enterprise administrators can navigate to Organization Settings → Actions → General → Action permissions and enforce:
- "Allow all actions"
- "Allow enterprise actions only"
- "Allow marketplace actions by GitHub and Verified Creators only"
- "Allow specified actions and reusable workflows"
- 5. Action Lifecycle, Unpublishing & Security Advisories
Once an action is published to GitHub Marketplace, maintaining ecosystem stability is paramount.
Unpublishing Constraints
To prevent supply chain disruptions across thousands of independent CI/CD workflows, GitHub restricts unpublishing actions. Once published:
Maintainers can publish new versions or update descriptions.
If an action must be permanently sunset, maintainers should add a deprecationMessage: in action.yml , update the README.md , and unlist the action via GitHub Support if necessary.
Deleting the repository immediately breaks all workflows referencing that action by repository path.
GitHub Security Advisories for Actions (GHSA)
When a vulnerability is discovered in an action (e.g., script injection or vulnerable dependencies):
Maintainers open a GitHub Security Advisory (GHSA) in the repository under the Security tab.
The maintainer requests a CVE identifier directly through GitHub's CNA (CVE Numbering Authority) workflow.
Maintainers collaborate on a patch in a private temporary fork.
Once patched, the maintainer publishes the fixed release (e.g., v1.2.1 and updates v1 ), and publishes the advisory.
GitHub automatically notifies all downstream consumers and Dependabot users across the platform.