(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=20.4 2020-10-19T20:59:16+00:00 2020-10-19T20:59:16+00:00 Paride Legovini paride.legovini@canonical.com 2020-10-19T20:59:16+00:00 urn:sha1:5a7f6818083118b45828fa0b334309449881f80a bddeb builds a .deb package using the template packaging files in packages/debian/. The new --packaging-branch flag allows to specify a git branch where to pull the packaging (i.e. the debian/ directory) from. This is useful to build a .deb package from master with the very same packaging which is used for the uploads. 2020-06-30T17:17:40+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-06-30T17:17:40+00:00 urn:sha1:66e114a660c53400e389f119781f378311b65108 caplog is only available in pytest itself from 3.0 onwards. In xenial, we only have pytest 2.8.7. However, in xenial we do have pytest-catchlog available (as python3-pytest-catchlog), so we use that where appropriate. 2020-06-08T16:49:12+00:00 Scott Moser smoser@brickies.net 2020-06-08T16:49:12+00:00 urn:sha1:3c551f6ebc12f7729a2755c89b19b9000e27cc88 This was painful, but it finishes a TODO from cloudinit/subp.py. It moves the following from util to subp: ProcessExecutionError subp which target_path I moved subp_blob_in_tempfile into cc_chef, which is its only caller. That saved us from having to deal with it using write_file and temp_utils from subp (which does not import any cloudinit things now). It is arguable that 'target_path' could be moved to a 'path_utils' or something, but in order to use it from subp and also from utils, we had to get it out of utils. 2020-05-02T00:57:24+00:00 Paride Legovini paride.legovini@canonical.com 2020-05-02T00:57:24+00:00 urn:sha1:4d2684848722cb2d469ad4fa60999bf81cf7056e Since upstream cloud-init has dropped python2 support, adapt remaining package build scripts and tools to python3 only Changes: * Do not template debian/rules as python3 is the only supported version * Drop six from requirements.txt * Makefile: drop everything related to Python 2 * run-container: install the CI deps only on ubuntu|debian * read-version: update the shebang to use Python 3 * brpm: read_dependencies(): drop unused argument * read-dependencies: switch to Py3 and drop the --python-version option * pkg-deps.json: drop the Python version field and update the redhat deps * pkg-deps.json: drop the unittest2 and contextlib2 renames * Update RPM the spec file to use Python 3 when building the RPM * bddeb: drop support for Python 2 2020-02-20T17:11:04+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-02-20T17:11:04+00:00 urn:sha1:4ad5c5d058cc9501ef2f294cb6430d9ffe372e7d * tools/read-version: don't enforce version parity in release branch CI We have a bootstrapping problem with new releases, currently. To take the example of 20.1: the branch that bumps the version fails CI because there is no 20.1 tag for it to use in read-version. Previously, this was solved by creating a tag and pushing it to the cloud-init repo before the commit landed. However, we have GitHub branch protection enabled, so the commit that needs to be tagged is not created until the pull request lands in master. This works around this problem by introducing a very specific check: if we are performing CI for an upstream release branch, we skip the read-version checking that we know will fail. * tools/make-tarball: add --version parameter When using make-tarball as part of a CI build of a new upstream release, the version it determines is inconsistent with the version that other tools determine. Instead of encoding the logic here (as well as in Python elsewhere), we add a parameter to allow us to set it from outside the script. * packages/bddeb: handle missing version_long in new version CI If we're running in CI for a new upstream release, we have to use `version` instead of `version_long` (because we don't yet have the tag required to generate `version_long`). 2018-05-03T02:03:23+00:00 Scott Moser smoser@ubuntu.com 2018-05-03T02:03:23+00:00 urn:sha1:d24057adbc70e7b034b8aca36c5351938b5de74a bddeb already supported passing in a '--release' and that would get into the changelog line. If you used bddeb to build packages for a PPA, and built multiple releases, then you would get the same version for each release, and launchpad would reject your upload. The change here means we get a ~16.04.1 (for xenial) suffix on the dpkg version. If the distro-info-data package is not installed, or the release is not known (such as the default "UNRELEASED"), then you get no suffix. 2018-05-01T21:38:41+00:00 Scott Moser smoser@ubuntu.com 2018-05-01T21:38:41+00:00 urn:sha1:26fbb1a0ce89451edad83a47054cacb6dd7b6dcc If you built packages with 'bddeb', each time it would create a new tarball with make-tarball. If you then tried to upload two different tarballs to launchpad (to a PPA), it would reject the second as the orig tarball already existed. This just supports looking in some places for a orig tarball and re-using if it is found. 2017-09-07T19:22:54+00:00 Scott Moser smoser@brickies.net 2017-08-29T13:59:20+00:00 urn:sha1:409918f9ba83e45e9bc5cc0b6c589e2fc8ae9b60 During boot, the usage of /tmp is not safe. In systemd systems, systemd-tmpfiles-clean may run at any point and clear out a temp file while cloud-init is using it. The solution here is to use /run/cloud-init/tmp. LP: #1707222 2017-09-01T02:01:57+00:00 Scott Moser smoser@brickies.net 2017-09-01T02:01:57+00:00 urn:sha1:fa266bf8818a08e37cd32a603d076ba2db300124 The ubuntu-init-switch module allowed the use to launch an instance that was booted with upstart and have it switch its init system to systemd and then reboot itself. It was only useful for the time period when Ubuntu was transitioning to systemd but only produced images using upstart. Also, do not run setup with --init-system=upstart. This means that by default, debian packages built with packages/bddeb will not have upstart unit files included. No other removal is done here. 2017-06-14T23:11:43+00:00 Chad Smith chad.smith@canonical.com 2017-06-14T23:11:43+00:00 urn:sha1:b23d9d7c5c112612dbaaf8c8371c9e735500b2eb read-dependencies now takes --test-distro param to indicate we want to install all system package depenencies to allow for testing and building for our continous integration environment. It allows us to install all needed deps on a fresh system with: python3 ./tools/read-dependencies --distro ubuntu --test-distro [--dry-run]. Additionally read-dependencies now looks at what version of python is running the script (py2 vs p3) and opts to install python 2 or 3 system deps respectively. This behavior can still be overridden with python3 ./tools/read-dependencies ... --python-version 2. There are also some distro-specific packaging and test dependencies, like devscripts, tox and libssl-dev on debian or ubuntu. Those pkg dependencies have now been broken out from common pkg deps to avoid trying to install them on centos/redhat/suse.