(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=22.1 2020-03-24T15:42:05+00:00 2020-03-24T15:42:05+00:00 Ryan Harper ryan.harper@canonical.com 2020-03-24T15:42:05+00:00 urn:sha1:9bb1ae9106ce1de4f53233faa329863c1191551a * tools: use python3 Switch tools/ to use python3 instead of python. At minimum this fixes building deb on python3 only releases like Focal. Applied via shell commands: $ grep 'usr/bin/.*python' tools/* 2>/dev/null | \ grep -v python3 | awk -F':' '{print $1}' | \ xargs -i sed -i -e '0,/python/s/python/python3/' {} * Use /usr/bin/env python3 to be virtualenv friendly 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`). 2019-04-23T17:07:39+00:00 Chad Miller millchad@amazon.com 2019-04-23T17:07:39+00:00 urn:sha1:3fb55ea85139f2d29ce32f124d099419fbd06f60 When the cloned branch was not the canonical upstream and tags were not available, tox would fail because tools/read-version would fail, and tragically never print the advice that is in tools/read-version about how to fix it. This changes tools/read-version to catch the exception that is elsewhere explicitly thrown and treat that too as an error it can handle. 2018-08-31T22:11:49+00:00 Joshua Powers josh.powers@canonical.com 2018-08-31T22:11:49+00:00 urn:sha1:8d9d4c8477732c5cc559eb10ddacef4598f93591 The error message when read-vesion is not very useful and does not help the end-user know how to overcome the issue. This adds a short message explaining that the user does not have the latest upstream tags and how to get those tags. 2018-01-24T15:25:48+00:00 Scott Moser smoser@ubuntu.com 2018-01-24T15:25:48+00:00 urn:sha1:30597f28512fafbe25486df5865b628d859486c6 read-version --json would report bad data when working in a worktree. This is just because in a worktree, .git is not a directory, but rather a metadata file that points to the another path. $ git worktree ../mytree $ cat ../mytree/.git gitdir: /path/to/cloud-init/.git/worktrees/mytree $ rm -Rf ../mytree; git worktree prune 2017-10-05T18:21:00+00:00 Scott Moser smoser@brickies.net 2017-10-05T18:21:00+00:00 urn:sha1:6eb4dc24fe314ce5c98b05b21988402cda95afce The tools that use "git describe" were just assuming a consisent number of characters in the hash. It seems ubuntu 16.04 would use 7 and later versions use 8. To avoid that discrepency in developer environments, set it to 8. 2017-01-23T14:39:01+00:00 Scott Moser smoser@brickies.net 2017-01-20T14:36:51+00:00 urn:sha1:a3376d45c83e90150d8de79a2b31282a7d760bd7 running 'make' on a git branch other than master would fail with complaint that the tools/read-version reported a different version than the code. Change to only consider tags starting with 0-9 in read-version. 2016-12-22T22:04:28+00:00 Jon Grimm jon.grimm@canonical.com 2016-11-22T23:09:53+00:00 urn:sha1:b2a9f33616c806ae6e052520a8589113308f567c This has been a recurring ask and we had initially just made the change to the cloud-init 2.0 codebase. As the current thinking is we'll just continue to enhance the current codebase, its desirable to relicense to match what we'd intended as part of the 2.0 plan here. - put a brief description of license in LICENSE file - put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0 - simplify the per-file header to reference LICENSE - tox: ignore H102 (Apache License Header check) Add license header to files that ship. Reformat headers, make sure everything has vi: at end of file. Non-shipping files do not need the copyright header, but at the moment tests/ have it. 2016-08-10T17:18:40+00:00 Scott Moser smoser@brickies.net 2016-08-10T17:18:40+00:00 urn:sha1:1e85ba042c786e56449642aec59874a9bb059262 commit 48ec60ae changed over several tools to use X.Y.Z-XXX-gHASH but missed tools/read-version. The end result was that check_version failed. 2016-08-09T06:59:29+00:00 Scott Moser smoser@brickies.net 2016-08-09T06:59:29+00:00 urn:sha1:537477335449c7730633d321905c57f694441eb3 Even if there is a .git directory, we can't use git if there is no git executable in the path. In that case just fall back to the cloud-init version.