Bump actions/stale from 10.0.0 to 10.2.0#46761
Conversation
f534148 to
145d9d8
Compare
Files inventory check summaryFile checks results against ancestor 86310699: Results for datadog-agent_7.78.0~devel.git.260.50fdb65.pipeline.100012664-1_amd64.deb:No change detected |
|
@dependabot rebase |
Bumps [actions/stale](https://github.com/actions/stale) from 10.0.0 to 10.2.0. - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@3a9db7e...b5d41d4) --- updated-dependencies: - dependency-name: actions/stale dependency-version: 10.2.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
145d9d8 to
50fdb65
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
devflow unqueued this merge request: It did not become mergeable within the expected time |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
## Pin GitHub Actions to SHA hashes This automated PR pins third-party GitHub Actions references from mutable tag versions (e.g., `@v4`) to their corresponding SHA hashes (e.g., `@abc123...`). The original tag is preserved as a comment for readability. Your workflows will work exactly the same way. Internal actions (under the `DataDog` organization) are not pinned. Read https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions for more details and info on how to configure this for entire repos. ### Why pin GitHub Actions? Git tags are mutable: they can be moved to point to different commits at any time. A compromised or malicious action maintainer could update a tag to inject arbitrary code into your CI workflows (see the [tj-actions incident](https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066)). Pinning to SHA hashes ensures you always run the exact code you reviewed, protecting your repository from supply chain attacks such as the tj-actions incident. ### What if something breaks? If a pinned action doesn't work for your use case, you can push a commit directly to this branch to fix it. As a last resort, reach out to **#sdlc-security** on Slack. ### Set up Dependabot or Renovate for automatic updates Once actions are pinned to SHA hashes, you should configure Dependabot or Renovate to receive weekly update PRs when new versions are available. In the case of Dependabot, create or update `.github/dependabot.yml`: ```yaml version: 2 updates: - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" groups: github-actions: patterns: - "*" open-pull-requests-limit: 10 ``` Dependabot will automatically propose PRs that update both the SHA hash and the version comment like [in this example](DataDog/datadog-agent#46761). --- *This PR was automatically generated by the GitHub Actions Pinning tool, owned by #sdlc-security.*
## Pin GitHub Actions to SHA hashes This automated PR pins third-party GitHub Actions references from mutable tag versions (e.g., `@v4`) to their corresponding SHA hashes (e.g., `@abc123...`). The original tag is preserved as a comment for readability. Your workflows will work exactly the same way. Internal actions (under the `DataDog` organization) are not pinned. Read https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions for more details and info on how to configure this for entire repos. ### Why pin GitHub Actions? Git tags are mutable: they can be moved to point to different commits at any time. A compromised or malicious action maintainer could update a tag to inject arbitrary code into your CI workflows (see the [tj-actions incident](https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066)). Pinning to SHA hashes ensures you always run the exact code you reviewed, protecting your repository from supply chain attacks such as the tj-actions incident. ### What if something breaks? If a pinned action doesn't work for your use case, you can push a commit directly to this branch to fix it. As a last resort, reach out to **#sdlc-security** on Slack. ### Set up Dependabot or Renovate for automatic updates Once actions are pinned to SHA hashes, you should configure Dependabot or Renovate to receive weekly update PRs when new versions are available. In the case of Dependabot, create or update `.github/dependabot.yml`: ```yaml version: 2 updates: - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" groups: github-actions: patterns: - "*" open-pull-requests-limit: 10 ``` Dependabot will automatically propose PRs that update both the SHA hash and the version comment like [in this example](DataDog/datadog-agent#46761). --- *This PR was automatically generated by the GitHub Actions Pinning tool, owned by #sdlc-security.* Co-authored-by: kemal.akkoyun <kemal.akkoyun@datadoghq.com>
## Pin GitHub Actions to SHA hashes This automated PR pins third-party GitHub Actions references from mutable tag versions (e.g., `@v4`) to their corresponding SHA hashes (e.g., `@abc123...`). The original tag is preserved as a comment for readability. Your workflows will work exactly the same way. Internal actions (under the `DataDog` organization) are not pinned. Read https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions for more details and info on how to configure this for entire repos. ### Why pin GitHub Actions? Git tags are mutable: they can be moved to point to different commits at any time. A compromised or malicious action maintainer could update a tag to inject arbitrary code into your CI workflows (see the [tj-actions incident](https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066)). Pinning to SHA hashes ensures you always run the exact code you reviewed, protecting your repository from supply chain attacks such as the tj-actions incident. ### What if something breaks? If a pinned action doesn't work for your use case, you can push a commit directly to this branch to fix it. As a last resort, reach out to **#sdlc-security** on Slack. ### Set up Dependabot or Renovate for automatic updates Once actions are pinned to SHA hashes, you should configure Dependabot or Renovate to receive weekly update PRs when new versions are available. In the case of Dependabot, create or update `.github/dependabot.yml`: ```yaml version: 2 updates: - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" groups: github-actions: patterns: - "*" open-pull-requests-limit: 10 ``` Dependabot will automatically propose PRs that update both the SHA hash and the version comment like [in this example](DataDog/datadog-agent#46761). --- *This PR was automatically generated by the GitHub Actions Pinning tool, owned by #sdlc-security.* Co-authored-by: julien.doutre <julien.doutre@datadoghq.com>
## Pin GitHub Actions to SHA hashes This automated PR pins third-party GitHub Actions references from mutable tag versions (e.g., `@v4`) to their corresponding SHA hashes (e.g., `@abc123...`). The original tag is preserved as a comment for readability. Your workflows will work exactly the same way. Internal actions (under the `DataDog` organization) are not pinned. Read https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions for more details and info on how to configure this for entire repos. ### Why pin GitHub Actions? Git tags are mutable: they can be moved to point to different commits at any time. A compromised or malicious action maintainer could update a tag to inject arbitrary code into your CI workflows (see the [tj-actions incident](https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066)). Pinning to SHA hashes ensures you always run the exact code you reviewed, protecting your repository from supply chain attacks such as the tj-actions incident. ### What if something breaks? If a pinned action doesn't work for your use case, you can push a commit directly to this branch to fix it. As a last resort, reach out to **#sdlc-security** on Slack. ### Set up Dependabot or Renovate for automatic updates Once actions are pinned to SHA hashes, you should configure Dependabot or Renovate to receive weekly update PRs when new versions are available. In the case of Dependabot, create or update `.github/dependabot.yml`: ```yaml version: 2 updates: - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" groups: github-actions: patterns: - "*" open-pull-requests-limit: 10 ``` Dependabot will automatically propose PRs that update both the SHA hash and the version comment like [in this example](DataDog/datadog-agent#46761). --- *This PR was automatically generated by the GitHub Actions Pinning tool, owned by #sdlc-security.* Co-authored-by: bjorn.antonsson <bjorn.antonsson@datadoghq.com>
Bumps actions/stale from 10.0.0 to 10.2.0.
Release notes
Sourced from actions/stale's releases.
Commits
b5d41d4build(deps-dev): bump lodash from 4.17.21 to 4.17.23 (#1313)dcd2b94Fix punycode and url.parse Deprecation Warnings (#1312)d6f8a33build(deps-dev): bump js-yaml from 4.1.0 to 4.1.1 (#1304)a21a081Fix checking state cache (fix #1136), also switch to octokit methods (#1152)9971854build(deps): bump actions/checkout from 4 to 6 (#1306)5611b9dbuild(deps): bump actions/publish-action from 0.3.0 to 0.4.0 (#1291)fad0de8Improves error handling when rate limiting is disabled on GHES. (#1300)39bea7dAdd Missing Input Reading foronly-issue-types(#1298)e46bbabbuild(deps-dev): bump@types/nodefrom 20.10.3 to 24.2.0 and document breakin...65d1d48build(deps-dev): bump eslint-config-prettier from 8.10.0 to 10.1.8 (#1276)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)