Bump actions/checkout from 4 to 5 in the github-actions group#2135
Conversation
Bumps the github-actions group with 1 update: [actions/checkout](https://github.com/actions/checkout). Updates `actions/checkout` from 4 to 5 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v5) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
Eliah Kagan (EliahKagan)
left a comment
Eliah Kagan (EliahKagan)
left a comment
There was a problem hiding this comment.
This is in good shape. It may seem obvious that upgrading actions/checkout to a newer version that uses a newer Node.js would be fine so long as all checks still pass, but there were a few things I looked at just to be sure:
Git version reporting
When actions/checkout finds git to use, it reports its version. This is useful for determining what version of git is running, which is relevant to us because when CI breaks, it's often because of an incompatibility between test fixture scripts and the git version on the runner. This new actions/checkout version still reports the Git version.
Node.js interaction with containers
The test-32bit jobs use containers of a different architecture than that of the host. The architectures are compatible in the sense that no QEMU emulation is required, but they are still different. Because actions/checkout is a JavaScript action, it runs in the environment of the job that uses it; when that job runs in a container, so does the action. But the action runs the host-native Node.js. This fails in such containers due to the necessary shared libraries for the host architecture not being present in the container, which we fix by installing libstdc++ in the container. Because this uses a newer version of Node.js, there are a few questions to ask about how that may be affected.
It turns out this is not affected. The fix is still needed, and it still works. The following are based on experiments done on two branches: this branch in my fork at 9fb3a40 as an actions/checkout@v4 baseline, and this other branch in my fork at e88c997 (associated with this test PR) for actions/checkout@v5.
(Two of the items below relate to Debian 12 vs. Debian 13. These only seek to rule out possible interaction with Node.js library dependencies. They are not an attempt to probe all possible changes that may occur if and when eventually moving to Debian 13.)
Is installing the host-native libstdc++ still sufficient?
Yes, as shown by how actions/checkout works both before and after the upgrade to v5 (and bolstered by the findings below).
Do containers still need the host-native libstdc++?
Yes. This is still needed with actions-checkout@v4 and with actions-checkout@v5.
Both fail in the actions/checkout step with the characteristic exec /__e/node24/bin/node: no such file or directory error without it. This is the same error as described and worked around in d221572 (#1687), except with node24 instead of node20, since actions/checkout@v5 uses Node 24. (The workaround shown in d221572 was refined in 64f2198 to just install libstdc++.)
Will containers still need the host-native libstdc++ in Debian 13?
As described in #1622 (comment) and #2109, we currently use Debian 12 containers, but we will likely move to Debian 13 containers at some point. Since the error where actions/checkout doesn't have the necessary libraries for Node.js occurs way before the test failure that currently blocks migration from Debian 12 to Debian 13, it's easy to verify that we will still need to install the host-native libstdc++ in the container even when we move to Debian 13, and that whether we use actions/checkout@v4 or use actions/checkout@v5 does not affect this.
Will installing the host-native libstdc++ still be sufficient in Debian 13?
Yes, with actions/checkout@v4 and with actions/checkout@v5, when libstdc++ is installed in the Debian 13 container, actions/checkout succeeds. (The jobs then fail in the way we currently expect due to git in Debian 13 being affected by #1622 as described in #1622 (comment) and #2109.)
|
Dependabot (@dependabot) merge |
dependabot
bot
deleted the
dependabot/github_actions/github-actions-a331d3ec2d
branch
1 participant
Bumps the github-actions group with 1 update: actions/checkout.
Updates
actions/checkoutfrom 4 to 5Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
08c6903Prepare v5.0.0 release (#2238)9f26565Update actions checkout to use node 24 (#2226)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 mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions