Skip to content

Bump actions/checkout from 4.4.0 to 7.0.1 - #5

Closed
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/github_actions/actions/checkout-7.0.1
Closed

dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/github_actions/actions/checkout-7.0.1

Conversation

@dependabot

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

Copy link
Copy Markdown

Bumps actions/checkout from 4.4.0 to 7.0.1.

Release notes

Sourced from actions/checkout's releases.

v7.0.1

What's Changed

Full Changelog: actions/checkout@v7...v7.0.1

v7.0.0

What's Changed

New Contributors

Full Changelog: actions/checkout@v6.0.3...v7.0.0

v6.1.0

What's Changed

https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/ for more details about this breaking change

Full Changelog: actions/checkout@v6.0.3...v6.1.0

v6.0.3

What's Changed

New Contributors

Full Changelog: actions/checkout@v6...v6.0.3

v6.0.2

What's Changed

... (truncated)

Changelog

Sourced from actions/checkout's changelog.

Changelog

v7.0.1

v7.0.0

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v5.0.1

v5.0.0

v4.3.1

v4.3.0

v4.2.2

v4.2.1

... (truncated)

Commits

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Aug 29, 2026
@dependabot
dependabot Bot force-pushed the dependabot/github_actions/actions/checkout-7.0.1 branch 2 times, most recently from 00ceff6 to bb1fb5d Compare August 29, 2026 17:03
@dependabot
dependabot Bot force-pushed the dependabot/github_actions/actions/checkout-7.0.1 branch from bb1fb5d to f36d800 Compare September 3, 2026 17:07
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.4.0 to 7.0.1.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@11d5960...3d3c42e)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: 7.0.1
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/github_actions/actions/checkout-7.0.1 branch from f36d800 to be1a598 Compare September 4, 2026 15:13
@dependabot @github

dependabot Bot commented on behalf of github Sep 4, 2026

Copy link
Copy Markdown
Author

Superseded by #15.

@dependabot dependabot Bot closed this Sep 4, 2026
@dependabot
dependabot Bot deleted the dependabot/github_actions/actions/checkout-7.0.1 branch September 4, 2026 15:56
karthik1729 added a commit that referenced this pull request Sep 12, 2026
…attach acts on a guess

Four ways the agent could lose or mislabel data, from the 2026-09-12 review. A `btrfs receive`
that exited 0 was trusted whatever it created: a peer holding the secret could land any name
under `snap/` and this node advertised it as held on the next beat — the created names are now
compared on both paths and anything but the one asked for is refused and removed. The cleanup of
a partial receive was `let _`; a delete that did not land is now part of the error, so a
truncated subvolume under the real name is never counted as held. The orphan-snapshot sweep
deletes with the uid it decided on, as the volume collector already did. Attaching to a detached
volume used an unguarded JSON-patch `add` of the whole `ownerReferences` array, which REPLACES
an existing list — two parents attaching at once lost an entry, and the retire sweep could
collect a volume a live worktree ran on; the empty arm now tests that the key is absent first.

Two more on the environment side. The intercept release read an API error on the Workspace GET
as "gone" and left the policy that opens the environment's namespace to that pod in place for
good; the error is propagated and the record kept for a retry. And a `Keep` decision (an API
blip mid-intercept) counted its workspace as stale, so the policy sweep deleted the grants of an
intercept that was still being rendered; a Keep's workspace is in force. The periodic volume
collector now asks every parent in the cluster whether it names the volume, the same predicate
the event-driven collector uses, rather than this node's parents alone.

Review findings #4, #5, #30, #36, #124, #125.
karthik1729 added a commit that referenced this pull request Sep 12, 2026
Review findings #3, #4, #5, #6, #7, #8, #9, #12, #15, #18, #19, #20, #82.

No listing here had a ceiling. `_catalog` stat-ed every unmarked image an
owner had to answer a page of two; `referrers` read every signature of a
subject on every pull of it; `api_refs`, `volumes`, `volumehistory` and
`index::list` each answered whatever was there. Each now takes `?n=`,
pages with the object store's own start-after where it has one, and says
so with a `Link`. `api_files` reads a size only when asked for one, and
`check_repo` scans as far as it can act and no further.

The ownership map's own bounds: a map write times out inside the lease
that authorised it rather than at it, the epoch is re-checked after every
bounded write, a prune pass gets one lease TTL as a whole instead of one
per entry, `all()` scans without the role lock held, and a clock reading
before a compiled-in floor decides nothing at all — it would have read
every live lease as expired and granted every repo away from its owner.

Also: the three image write routes get a body limit, and a by-tag push
hashes sha512 only for an image that actually holds a sha512 manifest.
`deepen-not` lists the repo's refs once and resolves a shorthand under
git's own prefixes, not by whichever ref happens to end in that name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants