Demo GitHub Actions Marketplace

GitHub Marketplace helps you extend workflows with community and partner Actions, applications, and services that streamline CI/CD tasks such as linting, testing, and deployment. In the Actions marketplace you can filter by use case (for example: API management, code review, linting) and install reusable Actions to automate routine checks. In this lesson we’ll add an automated linting step to a workflow so the repository runs static analysis on HTML, CSS, and JavaScript files. Running linters early helps surface quality and syntax issues before code is merged.

The image shows the GitHub Marketplace webpage, highlighting actions and extensions for enhancing workflow. It lists various tools like TruffleHog OSS and Super-Linter, with filters for sorting.

How to choose an Action

Search the Marketplace for relevant keywords, e.g., “lint”.
Look for a check/tick icon (verified Actions) — this indicates GitHub has vetted the publisher.
Always review the Action’s README and source code before adding it to important workflows.

Verified actions (the tick/check icon) indicate that GitHub has vetted the publisher. Prefer verified actions when possible, but always review the action’s documentation and code before using it in important workflows.

One widely used option is Super-Linter, a community-maintained Action that bundles multiple linters and formatters so you can validate many file types with a single step. The repository and Marketplace page list supported linters, configuration options, usage examples, and environment variables you can set to tune behavior.

The image is a screenshot of a GitHub Marketplace page for "Super-Linter," which is described as a collection of linters and code analyzers. The page includes features, licensing information, and contributor details.

Super-Linter configuration

You can configure which linters run, whether to lint the whole repository or only changed files, and which branch to compare against.
These options are typically set with environment variables on the uses: step that runs the Action.

The image is a screenshot of a GitHub page displaying the configuration options for the Super-Linter GitHub action, with a list of environment variables and their descriptions.

Example workflow (consolidated) Below is a concise, final YAML example that checks out the repository, verifies a core file exists, and runs Super-Linter. This workflow triggers on pushes and pull requests to main.

name: Game Quality Check

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      # Step 1: Check out the repository
      - name: Checkout Repository
        uses: actions/checkout@v4

      # Step 2: Simple validation: ensure index.html exists
      - name: Verify Core Files
        run: |
          if [ -f "index.html" ]; then
            echo "📄 index.html found. Ready for launch!"
          else
            echo "❌ index.html is missing! Game will not load."
            exit 1
          fi

      # Step 3: Run Super-Linter to validate code (HTML, JS, CSS)
      - name: Lint Code Base
        uses: github/super-linter@v5
        env:
          VALIDATE_ALL_CODEBASE: true     # true = lint entire repo; false = lint changed files only
          DEFAULT_BRANCH: main
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VALIDATE_HTML: true
          VALIDATE_JAVASCRIPT_ES: true
          VALIDATE_CSS: true

Key environment variables

Variable	Purpose	Example / Notes
`VALIDATE_ALL_CODEBASE`	Controls whether Super-Linter scans the entire repo or only changed files	`true` (scan everything) or `false` (scan changed files only)
`DEFAULT_BRANCH`	Branch to compare against when determining changed files	`main` or `master`
`GITHUB_TOKEN`	Token that allows the Action to access repo data and post results	use `${{ secrets.GITHUB_TOKEN }}`
`VALIDATE_HTML`	Enable/disable HTML linter	`true` / `false`
`VALIDATE_JAVASCRIPT_ES`	Enable/disable ESLint checks for JavaScript	`true` / `false`
`VALIDATE_CSS`	Enable/disable CSS linters (e.g., stylelint)	`true` / `false`

What happens during a run

The workflow checks out your repository.
It runs a quick validation step (example: ensure index.html exists).
It runs Super-Linter (as a Docker container) with the provided environment variables.
Super-Linter invokes the configured linters and returns any issues. If any linter exits non-zero, the Action step fails and the job is marked failed.

Example of the run output (abridged)

Run if [ -f "index.html" ]; then
  index.html found. Ready for launch!
fi

Run github/super-linter@v5
env:
  VALIDATE_ALL_CODEBASE: true
  DEFAULT_BRANCH: main
  GITHUB_TOKEN: ***
  VALIDATE_HTML: true
  VALIDATE_JAVASCRIPT_ES: true
  VALIDATE_CSS: true

/usr/bin/docker run --name ghcriosuperlinterv5 --workdir /github/workspace --rm \
  -e "VALIDATE_ALL_CODEBASE" -e "DEFAULT_BRANCH" -e "GITHUB_TOKEN" \
  -e "VALIDATE_HTML" -e "VALIDATE_JAVASCRIPT_ES" -e "VALIDATE_CSS" \
  ghcr.io/github/super-linter:5

Typical linter failure example (stylelint output)

File: [/github/workspace/style.css]
Found errors in [stylelint] linter!
Error code: 2. Command output:
style.css
  11:16  ×  Expected modern color-function notation     color-function-notation
  12:20  ×  Expected "0.1" to be "10"                  alpha-value-notation
  12:40  ×  Expected "2" to be "20"                   alpha-value-notation
  43:31  ×  Expected "#ffffff" to be "#fff"           color-hex-length
  41:51  ×  Expected modern color-function notation   color-function-notation

If Super-Linter reports issues, the linter step exits with a non-zero code and the workflow run is marked as failed. In the run shown below, the verification step passed but the lint step failed due to CSS/HTML problems.

The image shows a GitHub Actions workflow page with a failed lint-and-test job, displaying errors in a CSS file related to color notation and syntax issues.

Best practices and next steps

Start by running linters on the full codebase to get a baseline, then move to changed-files-only for performance.
Configure only the linters you need to reduce noise.
Use annotations and PR comments (if supported) to surface issues directly in pull requests.
When integrating third-party Actions, review the Action’s source and restrict permissions using least privilege.

Review third-party Action code and limit workflow permissions. Even verified Actions may have configuration or permission implications—always check the source repository and apply the principle of least privilege.

Links and references

Super-Linter repository: https://github.com/github/super-linter
GitHub Marketplace: https://github.com/marketplace
GitHub Actions docs: https://docs.github.com/actions

Watch Video

Practice Lab

Demo GitHub Actions

GitHub Copilot

Introduction

Git and GitHub Basics

GitHub Entities

GitHub Markdown

GitHub Desktop

GitHub Mobile

GitHub Repositories

Issues

Pull Requests

Discussions

Notifications

Gists, Wikis, and GitHub Pages

GitHub Actions

GitHub Copilot

GitHub Codespaces

Manage Your Work with GitHub Projects

Authentication and Security

GitHub Administration

Benefits of Open-Source Community

Benefits of Open Source – Applications

Demo GitHub Actions Marketplace

Watch Video

Practice Lab