Guest24897
/
DockerCLI
mirror of https://github.com/docker/cli.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
DockerCLI/dockerfiles/Dockerfile.vendor

44 lines
1.0 KiB
Docker
Raw Normal View History

Dockerfile: use syntax=docker/dockerfile:1 Now that HEREDOC is included in the stable Dockerfile syntax, we can use the latest stable syntax for all Dockerfiles. The recommendation for the stable syntax is to use `:1` (which is equivalent to "latest" stable syntax. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-17 05:37:08 -04:00
# syntax=docker/dockerfile:1
vendor with go mod Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2021-12-16 15:15:53 -05:00
update to go1.22.7 - https://github.com/golang/go/issues?q=milestone%3AGo1.22.7+label%3ACherryPickApproved - full diff: https://github.com/golang/go/compare/go1.22.6...go1.22.7 These minor releases include 3 security fixes following the security policy: - go/parser: stack exhaustion in all Parse* functions Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion. This is CVE-2024-34155 and Go issue https://go.dev/issue/69138. - encoding/gob: stack exhaustion in Decoder.Decode Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635. Thanks to Md Sakib Anwar of The Ohio State University (anwar.40@osu.edu) for reporting this issue. This is CVE-2024-34156 and Go issue https://go.dev/issue/69139. - go/build/constraint: stack exhaustion in Parse Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion. This is CVE-2024-34158 and Go issue https://go.dev/issue/69141. View the release notes for more information: https://go.dev/doc/devel/release#go1.23.1 Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
2024-09-05 11:51:27 -04:00
ARG GO_VERSION=1.22.7
Dockerfile: update ALPINE_VERSION to 3.20 Update to the current version of Alpine, which is also the default for the golang:alpine image Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2024-05-26 05:37:01 -04:00
ARG ALPINE_VERSION=3.20
vendor with go mod Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2021-12-16 15:15:53 -05:00
ARG MODOUTDATED_VERSION=v0.8.0
Dockerfile: add ALPINE_VERSION build-arg This allows us to pin to a specific version of Alpine, in case the golang:alpine image switches to a newer version, which may at times be incompatible, e.g. see https://github.com/moby/moby/issues/44570 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-12-04 08:01:30 -05:00
FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS base
Dockerfile: use GOTOOLCHAIN=local This may find its way into the official images, but until it does, let's make sure we don't get unexpected updates of go. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-09-26 06:43:38 -04:00
ENV GOTOOLCHAIN=local
vendor with go mod Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2021-12-16 15:15:53 -05:00
RUN apk add --no-cache bash git rsync
WORKDIR /src
FROM base AS vendored
Dockerfile.vendor: update GOPROXY to use default with fallback Use the default proxy, to assist with vanity domains mis-behaving, but keep a fallback for situations where we need to get modules from GitHub directly. This should hopefully help with the gopkg.in/yaml.v2 domain often going AWOL; #14 245.9 gopkg.in/yaml.v2@v2.4.0: unrecognized import path "gopkg.in/yaml.v2": reading https://gopkg.in/yaml.v2?go-get=1: 502 Bad Gateway #14 245.9 server response: Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe curl 'https://gopkg.in/yaml.v2?go-get=1' Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe From the Go documentation; https://go.dev/ref/mod#goproxy-protocol > List elements may be separated by commas (,) or pipes (|), which determine error > fallback behavior. When a URL is followed by a comma, the go command falls back > to later sources only after a 404 (Not Found) or 410 (Gone) response. When a URL > is followed by a pipe, the go command falls back to later sources after any error, > including non-HTTP errors such as timeouts. This error handling behavior lets a > proxy act as a gatekeeper for unknown modules. For example, a proxy could respond > with error 403 (Forbidden) for modules not on an approved list (see Private proxy > serving private modules). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-06-02 07:12:35 -04:00
ENV GOPROXY=https://proxy.golang.org|direct
vendor with go mod Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2021-12-16 15:15:53 -05:00
RUN --mount=target=/context \
--mount=target=.,type=tmpfs \
--mount=target=/go/pkg/mod,type=cache <<EOT
set -e
rsync -a /context/. .
./scripts/vendor update
mkdir /out
cp -r vendor.mod vendor.sum vendor /out
EOT
FROM scratch AS update
COPY --from=vendored /out /out
FROM vendored AS validate
RUN --mount=target=/context \
--mount=target=.,type=tmpfs <<EOT
set -e
rsync -a /context/. .
git add -A
rm -rf vendor
cp -rf /out/* .
./scripts/vendor validate
EOT
FROM psampaz/go-mod-outdated:${MODOUTDATED_VERSION} AS go-mod-outdated
FROM base AS outdated
RUN --mount=target=.,rw \
--mount=target=/go/pkg/mod,type=cache \
--mount=from=go-mod-outdated,source=/home/go-mod-outdated,target=/usr/bin/go-mod-outdated \
./scripts/vendor outdated