Checkpoint Lab — Composite Actions, JavaScript Actions, Docker Actions, and Custom Automation

1. Checkpoint scenario and safety boundary

Use a throwaway repository named gha-ch17-checkpoint. The lab creates no secret, package, release object, registry image, environment, cloud resource or self-hosted runner. It uses one local composite action and one SHA-pinned checkout action on ubuntu-24.04.

The “typed” contract is intentionally implemented as documented string semantics because custom-action metadata does not support workflow_call-style type declarations. mode is an enum string and repeat is an integer-like string validated before use.

2. Preflight and predictions

• Confirm the repository is disposable and contains no proprietary source.
• Confirm Actions is enabled and ubuntu-24.04 is available.
• Record the exact commit containing action.yml and the workflow before each run.
• Predict Revision A: checkout succeeds, local action starts, mode validation exits 64, output verification never runs.
• Predict Revision B: the same action implementation accepts strict, returns two outputs and produces no external side effect.

3. The action contract

# .github/actions/ch17-contract/action.yml
name: Chapter 17 checkpoint contract
description: Validate caller strings and return a non-sensitive summary
inputs:
  mode:
    description: "Enum string: strict or relaxed"
    required: true
  repeat:
    description: "Integer string from 1 through 3"
    required: false
    default: "1"
outputs:
  summary:
    description: Normalized summary
    value: ${{ steps.validate.outputs.summary }}
  contract_kind:
    description: Fixed classification
    value: ${{ steps.validate.outputs.contract_kind }}
runs:
  using: composite
  steps:
    - id: validate
      shell: bash
      env:
        MODE: ${{ inputs.mode }}
        REPEAT: ${{ inputs.repeat }}
      run: |
        set -euo pipefail
        case "$MODE" in
          strict|relaxed) ;;
          *) echo "unsupported mode" >&2; exit 64 ;;
        esac
        [[ "$REPEAT" =~ ^[1-3]$ ]] || {
          echo "repeat must be 1, 2, or 3" >&2
          exit 65
        }
        printf 'summary=mode-%s-repeat-%s
' "$MODE" "$REPEAT" >> "$GITHUB_OUTPUT"
        printf 'contract_kind=validated-string-contract
' >> "$GITHUB_OUTPUT"

4. Workflow Revision A — preserve a real validation failure

# .github/workflows/ch17-checkpoint.yml — Revision A
name: chapter17-checkpoint
on: workflow_dispatch
permissions: {}

jobs:
  validate:
    runs-on: ubuntu-24.04
    steps:
      - name: Record bounded run evidence
        shell: bash
        run: |
          echo "repository=$GITHUB_REPOSITORY"
          echo "sha=$GITHUB_SHA"
          echo "run=$GITHUB_RUN_ID attempt=$GITHUB_RUN_ATTEMPT"
          echo "runner_os=$RUNNER_OS arch=$RUNNER_ARCH"

      - name: Checkout exact caller revision
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - id: contract
        name: Execute contract
        uses: ./.github/actions/ch17-contract
        with:
          mode: unsupported
          repeat: '2'

      - name: Verify outputs
        shell: bash
        env:
          SUMMARY: ${{ steps.contract.outputs.summary }}
        run: test "$SUMMARY" = "mode-strict-repeat-2"

Commit Revision A and dispatch it. Preserve the run ID, attempt and source SHA. The expected first failure is the Execute contract step with exit 64 and the generic unsupported mode message. The verification step is skipped because the prior step failed.

5. Interpret before repairing

Do not modify action code, runner, permissions or checkout when this evidence matches the prediction. Those layers are healthy.

6. Workflow Revision B — least destructive repair

# Change exactly one caller value.
with:
  mode: strict
  repeat: '2'

Commit only that change and dispatch a new run. Expected output is mode-strict-repeat-2. Record the new source SHA and compare it with Revision A. The action metadata can be byte-for-byte identical across the two commits if only the workflow input changed.

7. Build an immutable release strategy without publishing anything

After Revision B succeeds, identify the reviewed commit that contains the action implementation you would release. Record a human version such as v1.0.0 and map it to the exact 40-character commit SHA. In a real action repository, you may publish that tag/release, but mandatory completion stops at the release plan.

Release record
name: v1.0.0
action path: .github/actions/ch17-contract
source commit: <REVIEWED_40_CHARACTER_SHA>
runtime: composite
required permissions: none
supported runner baseline: caller must provide Bash; lab verified ubuntu-24.04
inputs: mode=strict|relaxed; repeat=1|2|3
outputs: summary; contract_kind
external side effects: none

# Production caller pattern after release — pin the exact recorded commit.
- uses: OWNER/REPO/.github/actions/ch17-contract@REVIEWED_40_CHARACTER_SHA
  with:
    mode: strict
    repeat: '2'

A release tag can point reviewers to documentation, but callers that require immutable supply-chain identity should execute the full SHA.

8. Required evidence packet

9. Verification checklist

• ZIP/course example contains no real token, key or registry credential.
• Revision A exists as an independent failed run and was not overwritten.
• The first failure is action input validation, not checkout/path/syntax.
• Revision B changes only the caller mode value and succeeds.
• Output values are non-sensitive and deterministic.
• No write-all, secret dump, pull_request_target, Docker socket or privileged execution is used.
• Release plan records both human version and full immutable source SHA.
• External callers are instructed to pin the full SHA, not @main or only @v1.

10. Cleanup and rollback

There is no external infrastructure to roll back. Preserve non-sensitive screenshots/run IDs if desired, then delete the throwaway repository. If you optionally created a real release/tag for practice, remove only the exact disposable release/tag that you created after recording its SHA mapping.

11. What Chapter 17 adds to the operating model

You can now treat custom actions as versioned executable dependencies with an explicit step-level contract: metadata defines the surface, the execution model defines portability/runtime assumptions, the caller owns permissions, the implementation validates untrusted input, outputs remain small and non-sensitive, and release provenance binds human versions to immutable code. Chapter 18 expands reuse from individual actions and reusable workflows into Workflow Templates, Organization Standards, YAML Anchors, and Reuse Architecture.

Knowledge check

Official references and version notes

• GitHub Docs — About custom actions — execution-model and portability comparison.
• GitHub Docs — Metadata syntax reference — current action.yml inputs, outputs and runs models.
• GitHub Docs — Create a composite action — composite steps and GITHUB_ACTION_PATH.
• GitHub Docs — Create a JavaScript action — JavaScript packaging and runtime model.
• GitHub Docs — Create a Docker container action — Docker metadata, inputs and outputs.
• GitHub Docs — Dockerfile support for Actions — workspace, USER, ENTRYPOINT and CMD constraints.
• GitHub Docs — Managing custom actions — release management and immutable SHA references.
• actions/toolkit — official JavaScript action helper packages.
• GitHub Changelog — Node 20 deprecation — current Node 24 migration/removal schedule.