Skip to content

CI: Bump allow-list pin and quieten repeat summaries - #92

Merged
ModeSevenIndustrialSolutions merged 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:ci/harden-runner-allowlist-v0.16.1
Sep 8, 2026
Merged

CI: Bump allow-list pin and quieten repeat summaries#92
ModeSevenIndustrialSolutions merged 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:ci/harden-runner-allowlist-v0.16.1

Conversation

@ModeSevenIndustrialSolutions

@ModeSevenIndustrialSolutionsModeSevenIndustrialSolutions commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

CI: Bump allow-list pin and quieten repeat summaries

Two pieces of workflow housekeeping, applied identically across the
*-workflows estate.

1. Allow-list pin → v0.16.1

Repoints the shared lfreleng-actions/.github allow-list at
ec0736244fc776e326283c6af6840e30f316f63c (v0.16.1), up from v0.16.0.

Both forms that carry the reference move together:

FormWhere
allow_list.txt@the harden_runner_allowlist input default
config: '@'workflows that take no such input (release-drafter.yaml)

The four release examples under examples/ carry their own copy of the
pin in a HARDEN_RUNNER_ALLOWLIST env var, which their publishing jobs
pass to the loader. Those move too, so a caller copying an example does
not inherit a stale pin.

2. One allow-list summary per workflow

Every job loads the allow-list, and each invocation wrote the same static
block to the job summary — once per job rather than once per run,
crowding out the build, test and audit output a reader came for.

The action already exposes allow_list_summary for exactly this, so this
is configuration rather than a change to it. Suppressed everywhere except
the first invocation in each file.

invocations=32 emitting=5 (one per workflow file)

The most invocations in the estate. Per file:
build-test-release-multiarch.yaml goes from 10 blocks to 1,
build-test-release.yaml from 9 to 1, and both build-test.yaml and
build-test-multiarch.yaml from 6 to 1.

The release examples get the same treatment: each has two local loader
invocations (test-pypi then pypi), so the second is suppressed and
a copied caller emits one local block rather than two.

Scope note: once per workflow, not once per run

These are workflow_call reusable workflows, so they cannot see beyond
themselves. A caller invoking several still receives one block from each.
That is as far as a reusable workflow can enforce on its own behalf — a
large reduction on one per job, but not literally one per run, so worth
stating rather than implying.

Validation

actionlint clean on every workflow; zizmor reports no findings; all
prek hooks pass; aislop ci --changes --base upstream/main → 0 errors,
0 warnings. Verified that no stale allow-list SHA remains and that
exactly one invocation per file still emits.

@ModeSevenIndustrialSolutions
ModeSevenIndustrialSolutions requested review from a team and a balanced review from CopilotSeptember 3, 2026 13:54
@github-actionsgithub-actionsBot added the CI CI and tests updates label Sep 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Four release example workflows still explicitly use the superseded v0.16.0 allow-list pin.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates CI workflow allow-list references and reduces duplicate job summaries.

Changes:

  • Pins the shared allow-list to v0.16.1.
  • Suppresses repeated allow-list summaries after each workflow’s first invocation.
  • Leaves four release examples on the stale v0.16.0 pin.
File summaries
FileDescription
.github/workflows/release-drafter.yamlUpdates the direct allow-list reference.
.github/workflows/build-test.yamlUpdates the default pin and suppresses repeated summaries.
.github/workflows/build-test-multiarch.yamlUpdates the default pin and suppresses repeated summaries.
.github/workflows/build-test-release.yamlUpdates release workflow configuration.
.github/workflows/build-test-release-multiarch.yamlUpdates multi-architecture release configuration.
Review details
  • Files reviewed: 5/5 changed files
  • Comments generated: 2
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread.github/workflows/build-test-release-multiarch.yaml
Comment thread.github/workflows/build-test-release.yaml
CopilotAI review requested due to automatic review settings September 3, 2026 16:33
@ModeSevenIndustrialSolutions
ModeSevenIndustrialSolutionsforce-pushed the ci/harden-runner-allowlist-v0.16.1 branch from 1f79bd6 to dbcf9c7CompareSeptember 3, 2026 16:33

CopilotAI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Each release example still emits duplicate local allow-list summaries from its two publishing jobs.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details
  • Files reviewed: 9/9 changed files
  • Comments generated: 4
  • Review effort level: Balanced

Comment threadexamples/build-test-release-multiarch/gerrit.yaml
Comment threadexamples/build-test-release-multiarch/github.yaml
Comment threadexamples/build-test-release/gerrit.yaml
Comment threadexamples/build-test-release/github.yaml
Two unrelated pieces of workflow housekeeping.
The harden-runner allow-list now points at v0.16.1 of the shared
lfreleng-actions/.github list. Both forms that carry the reference
move together: the harden_runner_allowlist input default and the
literal config pin in the workflows that do not take that input.
Every job also loaded the allow-list and wrote the same static block
to the job summary, so a caller of one of these workflows saw it once
per job rather than once per run. The action already exposes
allow_list_summary for this, so the block is suppressed everywhere
except the first invocation in each file: what a job hardened against
is worth stating, but only the first time anyone reads it.
Reusable workflows cannot see beyond themselves, so this is once per
workflow rather than once per run. A caller invoking several still
gets one block from each, which is a large reduction on one per job
and as far as a workflow can enforce on its own behalf.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Matthew Watkins <mwatkins@linuxfoundation.org>
CopilotAI review requested due to automatic review settings September 3, 2026 16:41
@ModeSevenIndustrialSolutions
ModeSevenIndustrialSolutionsforce-pushed the ci/harden-runner-allowlist-v0.16.1 branch from dbcf9c7 to e5f146bCompareSeptember 3, 2026 16:41

CopilotAI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The verified pin and summary settings consistently implement the stated workflow housekeeping.

Review details
  • Files reviewed: 9/9 changed files
  • Comments generated: 0 new
  • Review effort level: Balanced

@zxiirozxiiro left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Auto-approved by agent: code-reviewed low risk. Same allow-list pin bump (v0.16.0→v0.16.1) + allow_list_summary:false as the noon series; Multi-Arch CI now green.

@ModeSevenIndustrialSolutions
ModeSevenIndustrialSolutions merged commit 51bf5cd into lfreleng-actions:mainSep 8, 2026
74 checks passed
@ModeSevenIndustrialSolutions
ModeSevenIndustrialSolutions deleted the ci/harden-runner-allowlist-v0.16.1 branch September 8, 2026 10:17
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CICI and tests updates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@ModeSevenIndustrialSolutions@zxiiro