- 20 May, 2022 2 commits
- 19 May, 2022 10 commits
- 18 May, 2022 7 commits
- 13 May, 2022 1 commit
-
-
Dduvall authored
-
- 12 May, 2022 2 commits
-
- 11 May, 2022 2 commits
- 06 May, 2022 10 commits
- 20 Apr, 2021 1 commit
-
-
Dduvall authored
To support scenarios where the `runs.as` or `lives.as` user/group already exists in the base image, pair the calls to `useradd` and `groupadd` with `getent` conditionals. Bug: T268819 Change-Id: I3aef722ac57b38695c7411e64b41589fad16e95b
-
- 18 Mar, 2021 1 commit
-
-
Dduvall authored
The `apt.proxies` field is now merged by appending second set of proxies to the original. Example: apt: proxies: - url: http://proxy.example:8080 variants: foo: apt: proxies: - url: http://proxy.example:8081 source: http://security.debian.org In the above example, the effective `apt.proxies` configuration for the `foo` variant would include both the base `proxy.example:8080` proxy and the `proxy.example:8081` proxy specific to the `security.debian.org` source. Bug: T277109 Change-Id: I64bad1eb1e6fb6712a5de178be3aa273936a2df5
-
- 12 Mar, 2021 1 commit
-
-
Dduvall authored
Defines a new `apt.proxies` field that allows users to specify http/https proxy URLs that apply to one or all APT sources. APT configuration for the proxies will be written prior to package installation and then removed. Both a shorthand and longhand configuration are supported. Example: apt: packages: [foo] proxies: [http://proxy.example:8080] Is a shorthand equivalent of: apt: packages: [foo] proxies: - url: http://proxy.example:8080 In which case, the following APT config is written before installing packages, proxying all http sources via `http://proxy.example:8080`. Acquire::http::Proxy "http://proxy.example:8080"; Example: apt: packages: [foo] proxies: - url: https://proxy.example:8081 source: https://security.debian.org In which case, the following APT config is written before installing packages, proxying only https requests to security.debian.org via `https://proxy.example:8081`. Acquire::https::Proxy::security.debian.org "https://proxy.example:8081"; Other changes include a refactoring of the `AptConfig.Packages` type and unmarshalling function. A formal type `AptPackages` is now defined, derived from `map[string][]string`, and the `UnmarshalJSON` member function moved there. This was done to avoid bloating of the general `AptConfig` unmarshal function with implementation for both fields (`packages` and `proxies`). The new `AptConfig.Proxy` type defines its own unmarshal function to support both shorthand and longhand configurations. Bug: T277109 Change-Id: I5b82efcc441e48890cfab62747519d8986d7e8ac
-
- 23 Feb, 2021 1 commit
-
-
Dduvall authored
To support image compositions that rely on copying files from one or more external images, allow `ArtifactsConfig.From` to be any valid image reference. Generalize `baseimage` validator as `imageref` and create a new `artifactfrom` validator alias for `imageref|variantref`. Use the new validator for `From`. Additionally, omits non-variant `From` references from the dependency graph. Change-Id: I3b92d815b62856fe5a8df836b37cce0043a74ffa
-
- 12 Feb, 2021 1 commit
-
-
BryanDavis authored
A `python` config block already triggered installing pip via easy_install which is pretty specific to python2 era usage. It then used pip to install/update pypi packages for setuptools, wheel, and tox. This change adds the pip package to that set of pypi install/update packages. This is useful to ensure that the resulting image is capable of installing manylinux2014 formatted wheels (pip >= 19.3). Debian Buster's python3-pip package is pip 18.1 which is too old to look for manylinux2014 wheels when installing packages such as cryptography which have stopped publishing wheels with the older manylinux1 and manylinux2010 platform tags. Existing pinning of pip to a version less than 21.0 is preserved for those poor, unloved python2 projects that linger in an ever colder and darker world hostile to their kind. Bug: T274435 Change-Id: I81f0af69dbd4f9202bc9736faf653813c81fc0ad
-
- 04 Feb, 2021 1 commit
-
-
Dduvall authored
Pip 21 has dropped support for Python 2 but is still strangely selected for installation when running setuptools with a python2 binary. Let's pin pip when a `version` is specified that starts with "python2". Note this will require python 2 users to explicitly specify `version: python2` even if their default `python` binary in the base image is for python 2. Bug: T273793 Change-Id: Id7d4315e345657ce7ac2efdd0b065d693e47b2f5
-