Tags: bazelbuild/rules_docker
Tags
toolchain: allow to configure build_tar target (#1937) python/cpython#18080 hasn't been back-ported to python3.8, which happens to be the default interpreter version in a lot of popular base docker images. This change in python's tarfile implementation affects the behavior of https://github.com/bazelbuild/rules_docker/blob/bdea23404dd256c7ae2f8e02d346428044cc7d91/container/archive.py#L144 used by a popular container_image rule. This means that images built by bazel in environments with different python3 versions will result in different image digests. Until the hermeticity of python toolchains is guaranteed, it may be useful to have a workaround for users who can provide their own build_tar tool, akin to https://github.com/kubernetes/repo-infra/blob/72a6f5d05659f7d255b51f152e0725adfe970718/tools/build_tar/buildtar.go
Make jar_app_layer._classpath_as_file public (#1947) * Rename jar_app_layer._classpath_as_file to classpath_as_file This is being done to make this attribute public so that callers can specify it. * Add classpath_as_file as argument to java_image * Add classpath_as_file as argument to groovy_image * Add classpath_as_file as argument to kt_jvm_image * Add classpath_as_file as argument to scala_image * Adds test for scala_image with classpath_as_file=True * Adds test for java_image with classpath_as_file = True * Adds test for groovy_image with classpath_as_file = True * Adds test for kt_jvm_image with classpath_as_file = True * Ignore new image tests under macos * Trigger build * Trigger build
Bump pyyaml from 5.1 to 5.4 in /repositories Bumps [pyyaml](https://github.com/yaml/pyyaml) from 5.1 to 5.4. - [Release notes](https://github.com/yaml/pyyaml/releases) - [Changelog](https://github.com/yaml/pyyaml/blob/master/CHANGES) - [Commits](yaml/pyyaml@5.1...5.4) --- updated-dependencies: - dependency-name: pyyaml dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Switch to non-api fetch URLs (#1732) This is a no-op change. These URLs have a few advantages: * GitHub is less aggressive at rate-limiting these URLs, and these URLs are easier to set up pass-through proxies for in an enterprise setting. * The URLs self-document which tag is being fetched, rather than requiring separate comments to track tags (but the sha256 ensures re-pointed tags will still halt builds). That said, there are sha1-equivalent URLs if we'd prefer to keep them. * The URLs have file extensions, so don't need a separate `type` attribute
PreviousNext