Skip to content

check-managed-files: check out the consumer repository inside the composite action #881

Open

Description

@kyle-sexton

Refs melodic-software/claude-code-plugins#4186. The one remaining slice of that tracker: the structural managed-files-guard fix.

Problem

Every caller of the check-managed-files composite action has to run its own actions/checkout (with fetch-depth: 0) before the guard, because the action checks out only the standards manifest source (.github/actions/check-managed-files/action.yml:160-167, path .managed-files-guard-standards). The standards component carries that caller step (components/managed-files-guard/managed-files-guard.yml:104-110, and managed-files-guard-fleet.yml), so every consumer repeats it and the guard fails closed when a caller forgets the fetch depth.

Fix

Move the consumer checkout into the composite action:

  • Add a step that checks out the consumer repository at the head ref with fetch-depth: 0 and persist-credentials: false, placed BEFORE the standards checkout. actions/checkout cleans the workspace, so running it after .managed-files-guard-standards would delete that tree.
  • Skip it when the mode resolves to skip, like the steps after it.
  • Stay compatible with callers that still run their own checkout, so the standards component can drop its step after a release rather than in lockstep.
  • Update the action README's caller example and its "pending" note, and release as usual.

The follow-up that drops the caller step from the standards component needs this change released first; it is not filed here.

Done when

  • grep -n 'actions/checkout' .github/actions/check-managed-files/action.yml shows two checkouts, and the consumer checkout's line number is lower than the standards one
  • actionlint exits 0 on the repository's workflows
  • The action's self-test passes on the PR both for a caller that runs its own checkout and for one that does not
  • ci-status is green on the PR head

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageNot yet classified. Floor until a type and one priority tier are set.status: readyTriaged, unblocked, and fully specified; eligible to pick up.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions