Skip to content

chore(deps): bump actions/stale from 10 to 11 in the github-actions group across 1 directory - #117

Merged
WomB0ComB0 merged 3 commits into
mainfrom
dependabot/github_actions/github-actions-84c3d95bcf
Aug 11, 2026
Merged

WomB0ComB0 merged 3 commits into
mainfrom
dependabot/github_actions/github-actions-84c3d95bcf

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 3, 2026

Copy link
Copy Markdown
Contributor

Bumps the github-actions group with 1 update in the / directory: actions/stale.

Updates actions/stale from 10 to 11

Release notes

Sourced from actions/stale's releases.

v11.0.0

What's Changed

Enhancement

Dependency Update

Full Changelog: actions/stale@v10...v11.0.0

v10.4.0

What's Changed

Bug Fix

Dependency Updates

New Contributors

Full Changelog: actions/stale@v10.3.0...v10.4.0

v10.3.0

What's Changed

Bug Fix

Dependency Updates

New Contributors

Full Changelog: actions/stale@v10...v10.3.0

v10.2.0

What's Changed

Bug Fix

Dependency Updates

New Contributors

Full Changelog: actions/stale@v10...v10.2.0

... (truncated)

Changelog

Sourced from actions/stale's changelog.

Changelog

[10.1.0]

What's Changed

[10.0.0]

What's Changed

Breaking Changes

Enhancement

Dependency Upgrades

Documentation changes

[9.1.0]

What's Changed

[9.0.0]

Breaking Changes

  1. Action is now stateful: If the action ends because of operations-per-run then the next run will start from the first unprocessed issue skipping the issues processed during the previous run(s). The state is reset when all the issues are processed. This should be considered for scheduling workflow runs.
  2. Version 9 of this action updated the runtime to Node.js 20. All scripts are now run with Node.js 20 instead of Node.js 16 and are affected by any breaking changes between Node.js 16 and 20.

... (truncated)

Commits
  • 4391f3d Fix 24 high severity vulnerabilities by overriding brace-expansion to 5.0.8 (...
  • eaf9131 refactor: update imports to use ES module syntax and improve test structure (...
  • See full diff in compare view

@dependabot @github

dependabot Bot commented on behalf of github Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Labels

The following labels could not be found: chore, deps. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@dependabot
dependabot Bot requested a review from WomB0ComB0 as a code owner August 3, 2026 06:24
@github-actions github-actions Bot added the area:ci GitHub Actions, workflows, CI label Aug 3, 2026
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>
@dependabot dependabot Bot changed the title chore(deps): bump actions/stale from 10 to 11 in the github-actions group chore(deps): bump actions/stale from 10 to 11 in the github-actions group across 1 directory Aug 3, 2026
@dependabot
dependabot Bot force-pushed the dependabot/github_actions/github-actions-84c3d95bcf branch from 91ccec9 to 00d991d Compare August 3, 2026 18:04
WomB0ComB0
WomB0ComB0 previously approved these changes Aug 4, 2026
Comment thread .github/workflows/stale.yml Fixed

Copilot AI 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.

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/stale from v10 to v11 in 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>
@WomB0ComB0 WomB0ComB0 added chore Maintenance, tooling, and housekeeping deps Dependency updates labels Aug 11, 2026
@WomB0ComB0

Copy link
Copy Markdown
Member

Resolved both blockers on this PR.

1. zizmor check failure — unpinned action reference (.github/workflows/stale.yml:28)

Root cause: stale.yml was never SHA-pinned on main (it was actions/stale@v10), so Dependabot did a tag→tag bump to @v11. zizmor enforces a blanket unpinned-uses policy, so the changed line surfaced as a new code-scanning alert — which is why scan / zizmor (SARIF upload job) passed while the zizmor code-scanning check failed.

Fix (e082581): pinned to the commit SHA using the repo's existing convention (@<sha> # vX.Y.Z, as used throughout the gh-aw workflows):

- uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0

4391f3da665fdf50b6810c1a66712fb9ba21aa93 was verified to be the target of both the v11 and v11.0.0 tags. Verified locally with zizmor v1.29.0: this file goes from 1 high finding (unpinned-uses) → 0 findings; actionlint passes clean.

This also self-heals the class of problem: Dependabot updates SHA pins in place and rewrites the trailing # vX.Y.Z comment, so future bumps to this action stay SHA-to-SHA rather than reintroducing a tag ref.

2. Dependabot: "The following labels could not be found: chore, deps"

.github/dependabot.yml requests both labels, but neither existed in the repo. Created them rather than stripping them from the config, since the labels are the intended taxonomy:

  • chore — Maintenance, tooling, and housekeeping (#6e7781, matching area:ci)
  • deps — Dependency updates (#0366d6)

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 unpinned-uses issue exists on main in labeler.yml, i18n-parity.yml, required.yml, and lychee.yml. They don't fail CI today because code scanning only reports alerts on changed lines, but each will block the next Dependabot bump that touches them. Left out of this PR to keep it scoped to the actions/stale bump.

@WomB0ComB0
WomB0ComB0 merged commit 8402668 into main Aug 11, 2026
21 checks passed
@dependabot
dependabot Bot deleted the dependabot/github_actions/github-actions-84c3d95bcf branch August 11, 2026 07:20
WomB0ComB0 added a commit to resq-software/dotnet that referenced this pull request Aug 16, 2026
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>
WomB0ComB0 added a commit that referenced this pull request Aug 20, 2026
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:ci GitHub Actions, workflows, CI chore Maintenance, tooling, and housekeeping deps Dependency updates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants