CodeQL autobuild uses the makefile, but outside of a container, so let's
set this variable to prevent it having to wait 10 seconds;
Use "make dev" to start an interactive development container,
use "make -f docker.Makefile " to execute this target
in a container, or set DISABLE_WARN_OUTSIDE_CONTAINER=1 to
disable this warning.
Press Ctrl+C now to abort, or wait for the script to continue..
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CodeQL 2.16.4's auto-build added support for multi-module repositories,
and is trying to be smart by searching for modules in every directory,
including vendor directories. If no module is found, it's creating one
which is ... not what we want, so let's give it a "go.mod".
Here's from a run in CI;
/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql/codeql version --format=json
{
"productName" : "CodeQL",
"vendor" : "GitHub",
"version" : "2.16.4",
"sha" : "9727ba3cd3d5a26f8b9347bf3c3eb4f565ac077b",
"branches" : [
"codeql-cli-2.16.4"
],
"copyright" : "Copyright (C) 2019-2024 GitHub, Inc.",
"unpackedLocation" : "/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql",
"configFileLocation" : "/home/runner/.config/codeql/config",
"configFileFound" : false,
"features" : {
"analysisSummaryV2Option" : true,
"buildModeOption" : true,
"bundleSupportsIncludeDiagnostics" : true,
"featuresInVersionResult" : true,
"indirectTracingSupportsStaticBinaries" : false,
"informsAboutUnsupportedPathFilters" : true,
"supportsPython312" : true,
"mrvaPackCreate" : true,
"threatModelOption" : true,
"traceCommandUseBuildMode" : true,
"v2ramSizing" : true,
"mrvaPackCreateMultipleQueries" : true,
"setsCodeqlRunnerEnvVar" : true
}
}
With 2.16.4, first it is unable to correlate files with the project, considering
them "stray" files;
Attempting to automatically build go code
/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql/go/tools/autobuild.sh
2024/03/16 15:54:34 Autobuilder was built with go1.22.0, environment has go1.21.8
2024/03/16 15:54:34 LGTM_SRC is /home/runner/work/cli/cli
2024/03/16 15:54:34 Found no go.work files in the workspace; looking for go.mod files...
2024/03/16 15:54:34 Found stray Go source file in cli/cobra.go.
2024/03/16 15:54:34 Found stray Go source file in cli/cobra_test.go.
2024/03/16 15:54:34 Found stray Go source file in cli/command/builder/client_test.go.
2024/03/16 15:54:34 Found stray Go source file in cli/command/builder/cmd.go.
...
It then tries to build the binary, but in go modules mode, which fails (it also
seems to be doing this for each and every directory);
Use "make dev" to start an interactive development container,
use "make -f docker.Makefile " to execute this target
in a container, or set DISABLE_WARN_OUTSIDE_CONTAINER=1 to
disable this warning.
Press Ctrl+C now to abort, or wait for the script to continue..
./scripts/build/binary
Building static docker-linux-amd64
+ go build -o build/docker-linux-amd64 -tags osusergo pkcs11 -ldflags -X "github.com/docker/cli/cli/version.GitCommit=38c3ff6" -X "github.com/docker/cli/cli/version.BuildTime=2024-03-16T17:20:38Z" -X "github.com/docker/cli/cli/version.Version=38c3ff6.m" -extldflags -static -buildmode=pie github.com/docker/cli/cmd/docker
cannot find package "github.com/docker/cli/cmd/docker" in any of:
/opt/hostedtoolcache/go/1.21.8/x64/src/github.com/docker/cli/cmd/docker (from $GOROOT)
/home/runner/go/src/github.com/docker/cli/cmd/docker (from $GOPATH)
make: *** [Makefile:62: binary] Error 1
2024/03/16 17:20:38 Running /usr/bin/make [make] failed, continuing anyway: exit status 2
2024/03/16 17:20:38 Build failed, continuing to install dependencies.
2024/03/16 17:20:38 The code in vendor/gotest.tools/v3/skip seems to be missing a go.mod file. Attempting to initialize one...
2024/03/16 17:20:38 Import path is 'github.com/docker/cli'
If also seems to be doing this for ... every package?
cat 0_codeql.log | grep 'you are not in a container' | wc -l
497
After which it starts to create modules out of every directory;
The code in internal/test/network seems to be missing a go.mod file. Attempting to initialize one...
The code in internal/test/notary seems to be missing a go.mod file. Attempting to initialize one...
The code in internal/test/output seems to be missing a go.mod file. Attempting to initialize one...
The code in opts seems to be missing a go.mod file. Attempting to initialize one...
The code in service seems to be missing a go.mod file. Attempting to initialize one...
The code in service/logs seems to be missing a go.mod file. Attempting to initialize one...
The code in templates seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor/dario.cat seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor/dario.cat/mergo seems to be missing a go.mod file. Attempting to initialize one...
...
Skipping dependency package regexp.
Skipping dependency package github.com/opencontainers/go-digest.
Skipping dependency package github.com/distribution/reference.
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (1ms)
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (0ms)
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (0ms)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The command path sent for `docker build` should be `docker` rather than
`docker build` to be consistent with the other command paths.
* `docker buildx build` has a command path of `docker buildx`
* `docker builder build` has a command path of `docker builder`
* `docker image build` has a command path of `docker image`
The reason this gets set to `docker buildx` rather than `docker buildx
build` is because the `build` portion of the command path is processed
by the plugin. So the command path only contains the portions of the
command path that were processed by this tool.
Since the `build` of `docker build` gets forwarded to `buildx`, it is
not included in the command path.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Mark pulling legacy image formats as deprecated, and describe the
DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE environment variable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was only used as part of container.RunStats, so moving the code
there instead as a non-exported type. The actual use also did not have to
handle concurrency, so the mutex is removed in the new location.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The daemonOSType variable is already set when collecting stats, so we unlikely
hit this code in practice, and it would only be set if `collect()` failed and
we never got a stats response. If we do need to get this information, let's use
the OSVersion we already obtained from the ping response.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Replace 'docker daemon' with the wording used for the preceeding table,
to make it extra-clear that those flags apply to the default bridge.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Added --detach/-d to stack rm. Setting --detach=false waits until
all of the stack tasks have reached a terminal state.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: George Margaritis <gmargaritis@protonmail.com>
Added --detach and --quiet/-q flags to stack deploy. Setting --detach=false
waits until all of the stack services have converged. Shows progress bars for
each individual task, unless --quiet/-q is specified.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: George Margaritis <gmargaritis@protonmail.com>
When a plugin is invoked, the docker cli will now set
`OTEL_RESOURCE_ATTRIBUTES` to pass OTEL resource attribute names to the
plugin as additional resource attributes. At the moment, the only
resource attribute passed is `cobra.command_path`.
All resource attributes passed by the CLI are prepended with the
namespace `docker.cli` to avoid clashing with existing ones the plugin
uses or ones defined by the user.
For aliased commands like the various builder commands, the command path
is overwritten to match with the original name (such as `docker
builder`) instead of the forwarded name (such as `docker buildx build`).
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
