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
Run ImageBuilder in a scenario where Docker is not installed, or the host has not passed in the Docker socket to the ImageBuilder container. It should still be able to do tasks like generate Dockerfiles and readmes.
Additional information (e.g. issue happens only occasionally)
There are two issues here.
One is that this CLI middleware runs for every command, outputting docker version and docker info before the command starts:
This is only useful for CI scenarios, not local dev scenarios, so it could be hidden behind a common CLI argument (like --ci or --no-ci) that we only use in pipelines.
The second is that, for commands with a ManifestFilterOptions, the default values for those options rely on output from the Docker CLI:
"OS type (linux/windows) of the Dockerfiles to build - wildcard chars * and ? supported (default is the Docker OS)",
()=>DockerHelper.OS.GetDockerName()),
For cases like generating readmes and Dockerfiles, it doesn't make sense to filter by arch or OS type. We could split ManifestFilterOptions into DockerfileFilterOptions and PlatformFilterOptions. DockerfileFilterOptions would let you filter by version, OS, or path. The other would let you filter by architecture and OS type (Linux/Windows). We could combine both of those for some commands as needed.
I would probably argue that it doesn't make sense for readme and Dockerfile generation to take path filters at all - our goal should be for generating those to be as quick and frictionless as possible.
The text was updated successfully, but these errors were encountered:
This is needed for dotnet/dotnet-docker#5654.
Steps to reproduce the issue
Additional information (e.g. issue happens only occasionally)
There are two issues here.
One is that this CLI middleware runs for every command, outputting
docker version
anddocker info
before the command starts:docker-tools/src/Microsoft.DotNet.ImageBuilder/src/ImageBuilder.cs
Lines 55 to 63 in eb53e75
This is only useful for CI scenarios, not local dev scenarios, so it could be hidden behind a common CLI argument (like
--ci
or--no-ci
) that we only use in pipelines.The second is that, for commands with a
ManifestFilterOptions
, the default values for those options rely on output from the Docker CLI:docker-tools/src/Microsoft.DotNet.ImageBuilder/src/Commands/ManifestFilterOptions.cs
Lines 29 to 37 in eb53e75
For cases like generating readmes and Dockerfiles, it doesn't make sense to filter by arch or OS type. We could split
ManifestFilterOptions
intoDockerfileFilterOptions
andPlatformFilterOptions
.DockerfileFilterOptions
would let you filter by version, OS, or path. The other would let you filter by architecture and OS type (Linux/Windows). We could combine both of those for some commands as needed.I would probably argue that it doesn't make sense for readme and Dockerfile generation to take path filters at all - our goal should be for generating those to be as quick and frictionless as possible.
The text was updated successfully, but these errors were encountered: