Feature request: allow selected action owners to be explicitly excluded from lockfile pinning

Open
  • Is something wrong?
#194 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, go
Domain
cli, security

Research direction

Start by tracing how gh actions-lock resolves workflow refs, reports findings such as self-repository-action, and verifies lockfile entries; then inspect runtime enforcement and lockfile parsing. The issue names no source files or tests, so locate those entry points first. Done means exclusions are recorded with reasons in the lockfile, reported during resolution, and treated as compliant by verification and enforcement only when listed.

Written by the indexing model from the issue text.

Description

feature-request

Problem

Our workflows mix public GitHub-maintained actions with internal actions published by our own organization, e.g.:

steps:
  - uses: actions/checkout@v7
  - uses: internal-action/build-image@v1

We want SHA-locked integrity for third-party/public actions (actions/*), but our internal actions are deliberately consumed via a floating major tag (@v1). They are released frequently under our own access controls and review process, and we want consumers to pick up patch releases without a lockfile change for every internal release.

Today gh actions-lock has no way to exclude specific actions or owners. Because enforcement requires every dependency of an onboarded workflow to be present in actions.lock, our only options are:

  1. Lock internal actions too and run --relock constantly (heavy churn for every internal release), or
  2. Leave the whole workflow un-onboarded, losing protection for the public actions as well.

Neither is a good fit. Option 2 in particular pushes teams to skip locking entirely.

Proposal

Support an explicit, auditable exclusion recorded in the lockfile itself (not only as a CLI flag), so the runtime can tell "intentionally unlocked" apart from "missing":

# .github/workflows/actions.lock
unlocked:
  - owner: internal-action        # or a pattern like 'my-org/*'
    reason: 'Internal actions, governed by org release process'

Suggested behavior:

  • gh actions-lock skips resolution for matching refs and reports them as an informational finding (similar to self-repository-action), never silently.
  • --verify / --verify-local treat matching refs as compliant only if they are listed under unlocked.
  • Runtime enforcement accepts listed refs unpinned and still requires everything else to be locked.
  • Optionally, restrict eligible owners (e.g. same owner/org as the repository, or an org-level policy) so this can't be used to unlock arbitrary third-party actions.
Dominant language
Go
Stars
253
Forks
15
Avg merge
19h 30m
Merged PRs (30d)
60

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-actions-lock

All issues in github/gh-actions-lock

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.