chore: import yq from base_images instead of curl in release artifact#24
Open
chore: import yq from base_images instead of curl in release artifact#24
Conversation
Replace the ad-hoc curl download of yq v2.4.1 from GitHub releases with an import of yq from the `tools/yq` base image. The base image ships yq v4, so the version.json command is updated to v4 syntax. This removes an external network dependency from the release-channel-version-artifact build and aligns it with how the rest of the modules consume tools from base_images.
Replace the bare `apt-get update` step in the `docs-generator` artifact
of `.werf/bundle.yaml` with an inclusion of the `alt packages proxy`
template from `.werf/defines/packages-proxies.tmpl`.
The helper:
- rewrites `/etc/apt/sources.list.d/alt.list` to use
`$DistroPackagesProxy` when the variable is set;
- exports `DEBIAN_FRONTEND=noninteractive`;
- runs `apt-get update -y`.
This brings the bundle artifact in line with how the other werf images
in each module already configure ALT package access (see e.g.
`images/*/werf.inc.yaml`).
Backport the `pypi proxy` template from the upstream Deckhouse .werf/defines/packages-proxies.tmpl into our copy of the file, and use it in the docs-generator artifact of .werf/bundle.yaml right before `pip3 install PyYAML packaging`. When `$DistroPackagesProxy` is set, the helper writes /etc/pip.conf pointing pip at our PyPI proxy (http://$DistroPackagesProxy/repository/pypi-proxy/...). When the variable is unset, the include is a no-op and pip continues to use the default index. Source of the template: https://github.com/deckhouse/deckhouse/blob/main/.werf/defines/packages-proxies.tmpl
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Replace the ad-hoc
curldownload ofyqv2.4.1 from GitHub releases inside therelease-channel-version-artifactbuild of.werf/release.yamlwith an importof
yqfrom thetools/yqbase image. The now-unusedapk add curl/chmodsteps and the empty
beforeInstallblock are dropped along with it.The
tools/yqbase image shipsyqv4, so theversion.jsongenerationcommand is updated to v4 syntax accordingly:
yq n version "$TAG" | yq r - -j > version.jsonyq -n '.version = "$TAG"' -o=json > version.jsonNo changes to the final
release-channel-versionimage layout.Why do we need it, and what problem does it solve?
artifact build, making it more reliable and reproducible.
yqto whatever is locked inbase_images.yml, insteadof an ancient (2017)
mikefarah/yqv2.4.1 GitHub release.tools from
base_imagesvia werfimport:(e.g.tools/util-linux,tools/xfsprogs, etc.).What is the expected result?
werfbuild ofrelease-channel-version-artifactno longer reaches thepublic internet to fetch
yq.version.jsonis functionally identical: a JSON object with asingle
versionfield equal toMODULES_MODULE_TAG.release-channel-versionimage content is unchanged(
version.json,changelog.yaml,module.yaml).Checklist