You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building a Docker Container which contains a COPY --link x y command, commands which reference this path fail stating
0.036 runc run failed: unable to start container process: error during container init: mkdir /src: not a directory
I have builds which succeed with the use of --link using the same version of the runner. However, all new builds fail consistently now. If it isn't the runner itself, then it could be the underlying disk infrastructure.
FWIW - All our actions are pinned to tags via hashes, so there has been no change to the action code we run.
Platforms affected
Azure DevOps
GitHub Actions - Standard Runners
GitHub Actions - Larger Runners
Runner images affected
Ubuntu 20.04
Ubuntu 22.04
Ubuntu 24.04
macOS 11
macOS 12
macOS 13
macOS 13 Arm64
macOS 14
macOS 14 Arm64
Windows Server 2019
Windows Server 2022
Image version and build link
Fails on
Image: ubuntu-22.04
Version: 20240616.1.0
Last passing build was
Image: ubuntu-22.04
Version: 20240616.1.0
Is it regression?
No?
Expected behavior
Successful container build
Actual behavior
Any Dockerfile reference to the path containing a link fails with the following error
0.036 runc run failed: unable to start container process: error during container init: mkdir /src: not a directory
Repro steps
A simple way to reproduce this is to build:
FROM node:18-alpine AS base
WORKDIR /src
COPY --link package.json package-lock.json .
RUN ls -la /src
It will fail with the above error message.
Removing --link from the COPY results in a successful build.
The text was updated successfully, but these errors were encountered:
Description
When building a Docker Container which contains a
COPY --link x y
command, commands which reference this path fail statingI have builds which succeed with the use of
--link
using the same version of the runner. However, all new builds fail consistently now. If it isn't the runner itself, then it could be the underlying disk infrastructure.FWIW - All our actions are pinned to tags via hashes, so there has been no change to the action code we run.
Platforms affected
Runner images affected
Image version and build link
Fails on
Last passing build was
Is it regression?
No?
Expected behavior
Successful container build
Actual behavior
Any Dockerfile reference to the path containing a link fails with the following error
Repro steps
A simple way to reproduce this is to build:
It will fail with the above error message.
Removing
--link
from theCOPY
results in a successful build.The text was updated successfully, but these errors were encountered: