(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-08-27T14:37:14+00:00 Paride Legovini paride.legovini@canonical.com 2020-08-27T14:37:14+00:00 urn:sha1:575750ac4a3abb6fdfa45e2cc65186df291d8ddf 456fb55744a1acc6bd2f464b7656a9c33d0b7ac5 made tools/read-dependencies and package/brpm distinguish between build dependencies and runtime dependencies, however packages/redhat/cloud-init.spec.in expects all the dependencies to be in the 'requires' list, thus missing some build dependencies. This change makes cloud-init.spec use 'buildrequires' too. The build happens to succeed without python3-devel on the epel-8 copr chroot as it pulls in the epel-rpm-macros package, which in turn depends on python3-devel. In other words the dependency is satisfied by chance. Packages building for Python 3 need to explicitly specify BuildRequires: python3-devel, see: [1]. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ 2020-07-24T17:59:49+00:00 Ryan Harper ryan.harper@canonical.com 2020-07-24T17:59:49+00:00 urn:sha1:456fb55744a1acc6bd2f464b7656a9c33d0b7ac5 tools/read-dependencies: - Add parameters --build-requires, --runtime-requires - Sort dependency output before printing package/brpm - use --build-requires, --runtime-requires to separate build/vs runtime package reqs. LP: #1886107 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-04-24T13:26:51+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-04-24T13:26:51+00:00 urn:sha1:38a7e6e9756fdab31264c0d6e93d20432ed111ac These libraries provide backports of Python 3's stdlib components to Python 2. As we only support Python 3, we can simply use the stdlib now. This pull request does the following: * removes some unneeded compatibility code for the old spelling of `assertRaisesRegex` * replaces invocations of the Python 2-only `assertItemsEqual` with its new name, `assertCountEqual` * replaces all usage of `unittest2` with `unittest` * replaces all usage of `contextlib2` with `contextlib` * drops `unittest2` and `contextlib2` from requirements files and tox.ini It also rewrites some `test_azure` helpers to use bare asserts. We were seeing a strange error in xenial builds of this branch which appear to be stemming from the AssertionError that pytest produces being _different_ from the standard AssertionError. This means that the modified helpers weren't behaving correctly, because they weren't catching AssertionErrors as one would expect. (I believe this is related, in some way, to https://github.com/pytest-dev/pytest/issues/645, but the only version of pytest where we're affected is so far in the past that it's not worth pursuing it any further as we have a workaround.) 2020-03-17T19:48:51+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-03-17T19:48:51+00:00 urn:sha1:b9ff0dc950558ecd2a8469eded26bd6ae4082771 2020-03-10T17:26:05+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-03-10T17:26:05+00:00 urn:sha1:986f37b017134ced5d9dd38b420350916297002b As the nose docs[0] themselves note, it has been in maintenance mode for the past several years. pytest is an actively developed, featureful and popular alternative that the nose docs themselves recommend. See [1] for more details about the thinking here. (This PR also removes stale tox definitions, instead of modifying them.) [0] https://nose.readthedocs.io/en/latest/ [1] https://lists.launchpad.net/cloud-init/msg00245.html 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`).