chore(deps): bump actions/stale from 10 to 11 in the github-actions group across 1 directory - #117
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Bumps the github-actions group with 1 update in the / directory: [actions/stale](https://github.com/actions/stale). Updates `actions/stale` from 10 to 11 - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@v10...v11) --- updated-dependencies: - dependency-name: actions/stale dependency-version: '11' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
91ccec9 to
00d991d
Compare
There was a problem hiding this comment.
Pull request overview
Updates the repository’s stale-issue/PR automation workflow to use the latest major version of actions/stale, keeping housekeeping behavior current while retaining the existing configuration.
Changes:
- Bump
actions/stalefromv10tov11in the stale workflow.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
zizmor enforces a blanket `unpinned-uses` policy, so tag refs are rejected. `stale.yml` was never SHA-pinned on main (`actions/stale@v10`), so Dependabot bumped tag -> tag (`@v11`) and the code-scanning `zizmor` check flagged the changed line as a new alert. Pinning to 4391f3da (= tags v11 and v11.0.0, verified identical) clears the alert. It also fixes this going forward: Dependabot updates SHA pins in place and rewrites the trailing `# vX.Y.Z` comment, so future bumps stay SHA-to-SHA instead of reintroducing a tag ref. Verified locally with zizmor v1.29.0: this file goes from 1 high finding (unpinned-uses) to 0. actionlint passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Resolved both blockers on this PR. 1. Root cause: Fix (e082581): pinned to the commit SHA using the repo's existing convention ( - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
This also self-heals the class of problem: Dependabot updates SHA pins in place and rewrites the trailing 2. Dependabot: "The following labels could not be found:
Applied both to this PR. Future Dependabot PRs will label themselves without the warning. Note Pushing to this branch means Dependabot will stop rebasing it. That's intentional here — the pin is the desired end state, not something to be overwritten by a rebase. Remaining, tracked separately: the same |
This repo pins everything by hand and had no mechanism to move any of it: 47 NuGet packages under Central Package Management, 11 actions pinned to commit SHAs, no dependabot.yml and no Renovate config. Pins without an updater are pins that rot — including security pins. That risk is not hypothetical here. Directory.Packages.props already carries a hand-written transitive pin forcing System.Text.Json off the vulnerable <=8.0.4 line (CVE-2024-43485 / GHSA-8g4q-xg66-9fp4). Someone had to notice that. This automates noticing the next one. Three update streams: nuget / root CPM. All versions live in one Directory.Packages.props, so bumps are edits to that single file. nuget /templates/resq-service the `dotnet new` template ships its own Directory.Packages.props and is restored outside the root tree (see NuGet.config), so the root scan never reaches it. Kept separate because template bumps change what downstream services scaffold with. github-actions / SHA pins. Dependabot updates them in place and rewrites the trailing `# vX.Y.Z` comment, so pins stay pins. Grouping is deliberate. Microsoft.Extensions/EF Core/AspNetCore ship as one versioned wave and fail to restore against each other if split. ResQ.BuildingBlocks.* are this repo's own packages, versioned together off one MinVer tag, so ungrouped they would open eight near-identical template PRs on every release. github/gh-aw-actions* is ignored: it is version-locked to the gh-aw compiler and rewritten into the *.lock.yml files by `gh aw compile`, so a bump here is reverted on the next compile. Verified: config parses as valid YAML v2; every group pattern was matched against the 47 package ids actually present, with zero dead patterns. The `chore` and `deps` labels were created first — a config naming labels that do not exist makes Dependabot refuse to label its PRs, which is exactly what happened in resq-software/docs#117. Co-authored-by: Mike Odnis <mikeodnis3242004@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…found (#124) * fix(ci): drop removed --exclude-mail flag breaking lychee since May The weekly lychee job has failed 14 consecutive scheduled runs (every run since 2026-05-11). The cause is not external link flake, which the workflow comment anticipates — lychee never checked a single link: error: unexpected argument '--exclude-mail' found Usage: lychee ... --include-mail[=<false|true>] [inputs]... Upstream removed `--exclude-mail` and inverted it to `--include-mail`. lychee-action is pinned by SHA but tracks the latest lychee binary (0.24.2 today), so the flag vanished under a pinned action and the job has aborted during argument parsing ever since. Mail is now excluded by default (`--include-mail` = "Also check email addresses", default false), so deleting the flag preserves the original intent exactly rather than changing what gets checked. Also pins actions/checkout and actions/cache to commit SHAs, and sets `persist-credentials: false` on checkout. The pin is required by the same blanket `unpinned-uses` policy that broke #117; the credentials flag is needed because pinning edits the checkout line, which would otherwise surface the pre-existing `artipacked` finding as a new alert on a changed line. This job only reads files, so it never needs the token persisted. Verified: lychee 0.24.2 --help confirms --exclude-mail is gone and --include-mail defaults to false. zizmor v1.29.0 on this file goes from 3 findings (2 high unpinned-uses, 1 artipacked) to 0. actionlint passes. Note: #121 attempted to fix this by committing six .lycheecache entries. That could not have worked — all six are 200s (caching successes cannot suppress an argument-parsing abort) and --max-cache-age 1d expires them within a day. Left in place as harmless; it is dead weight, not a fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ci): scope lychee to external links only With the argument-parsing abort fixed, lychee ran for the first time since May and failed with 11,529 errors out of 34,557 links. None were external-link problems: ~11,380 file:// local links (mostly generated SDK API doc anchors) 148 root-relative links (/sdks/typescript) that cannot resolve Both classes are internal links, which this workflow explicitly does not own — see its own header: "Internal MDX link integrity is enforced by `mint broken-links` in required.yml." lychee was walking every internal link in the docs tree, including the generated Python/TS API reference, and that was being misread as "external link flake" for months. Two flags are needed, and both are required — neither works alone: --scheme http/https confines checking to external URLs. Measured with --dump over identical inputs: 16,257 links -> 2,984, zero file:// surviving the filter. --root-dir root-relative links fail during *resolution*, which happens before scheme filtering, so --scheme alone cannot suppress them (confirmed: --exclude '^/' has no effect either). --root-dir lets them resolve to file:// URLs, which the scheme filter then excludes. Verified repo-wide: 148 resolution errors -> 0. --root-dir does not turn this into a second internal link checker: the resolved file:// links are excluded, never fetched. Rejected --base-url, which would instead point all 148 at the live site — locally that timed out on all inputs and took 80s for one file. Last verified CI run on this branch (31910818811) had all 2,972 external links passing, with 148 resolution errors as the only remaining failure; this commit removes those. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: resolve failing CI (run 31911555547) * fix(docs): complete the ResQ-type cross-link fix in generated .NET docs The automated fix in #124 retargeted ResQ.Clients.CoordinationHceClient but missed the other two ResQ types mapped to learn.microsoft.com, and skipped ScenarioRunner.ValidateLocation entirely. Lychee on that branch went 12 -> 4 errors, with all four being the same generator bug: learn.microsoft.com/en-us/dotnet/api/resq.clients.infrastructureapiclient x2 learn.microsoft.com/en-us/dotnet/api/resq.core.location x2 Both are our own types; Microsoft does not document them, so both 404. Retargeted to the sibling generated pages, matching the relative-link form #124 already established. Both targets verified present in-tree. This is a stopgap, not the fix. These files are regenerated output -- api-docs.dotnet.yml clears sdks/dotnet/api/ before copying fresh output over it -- so this is discarded on the next api-docs run from resq-software/dotnet-sdk. The generator bug is filed as resq-software/dotnet-sdk#93. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: resq-sw <engineer@resq.software>
Bumps the github-actions group with 1 update in the / directory: actions/stale.
Updates
actions/stalefrom 10 to 11Release notes
Sourced from actions/stale's releases.
... (truncated)
Changelog
Sourced from actions/stale's changelog.
... (truncated)
Commits
4391f3dFix 24 high severity vulnerabilities by overriding brace-expansion to 5.0.8 (...eaf9131refactor: update imports to use ES module syntax and improve test structure (...