Skip to content

Exclude dir - #4

Draft
samuelburnham wants to merge 5 commits into
devfrom
exclude-dir
Draft

Exclude dir#4
samuelburnham wants to merge 5 commits into
devfrom
exclude-dir

Conversation

@samuelburnham

Copy link
Copy Markdown
Member

Adds a ! prefix to the lake_package_directory arg which will exclude the given pattern from the paths that lean-update runs over.

Also bumps flake.lock for lean4-nix v4.33.1

A `/**` sweep takes every package under a directory, which is the wrong
granularity when one package in the tree must not move — a benchmark
pinned to an old toolchain on purpose, say. Without a way to carve it
back out, the whole glob has to be abandoned for an explicit list that
goes stale as packages are added.

An entry prefixed with `!` now subtracts: it names a directory and drops
that directory together with everything beneath it, so
`benchmarks/** !benchmarks/pinned` covers the tree and spares the one
package.

Exclusions live in `lake_package_directory` rather than in an input of
their own so that no step invoking the action needs a second environment
variable kept in sync with the first.

Matching compares path components, not string prefixes, so
`!benchmarks/slow` cannot swallow `benchmarks/slowfixture`, while
trailing slashes and `./` prefixes still name the same directory. An
exclusion carrying a glob is rejected, since it already reaches its whole
subtree, and one matching nothing is reported: a typo there silently
updates the package it was meant to protect.
Comment thread .github/workflows/e2e_test.yml Fixed
Without a `permissions` block the jobs run with whatever the repository
grants by default, which on many repositories is write access to
contents, issues, and pull requests. The E2E jobs update fixtures only
inside the runner's own checkout and never write back, and the action's
`gh` calls read the public list of Lean releases, so `contents: read`
covers everything they do.
Neither workflow writes to the repository: both build and assert inside
the runner's own checkout, and the `gh` calls underneath read public
data. Without a `permissions` block they ran with whatever the
repository grants by default, which is commonly write access to
contents, issues, and pull requests.
The App token existed only to work around GitHub's guard against a
workflow triggering itself, which leaves a GITHUB_TOKEN pull request
with no CI runs until a maintainer releases them. Trading that back for
one fewer credential to install and rotate means the self-update PR
opens with checks pending until someone pushes to the branch or closes
and reopens it.

The job needs contents and pull-requests write to open the PR, and
issues write for the default `on_update_fails: issue` path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants