| Age | Commit message (Collapse) | Author |
|---|
|
We have replicated their functionality in the new integration testing
framework, and have seen that running for long enough to be confident in
relying on it.
cloud_tests are still used in cloud-init's nightly test runs: this is
only modifying what we run in Travis.
|
|
|
|
This excludes Python 3.4, as there are currently test failures there;
that will be addressed separately.
|
|
`IMAGE_SOURCE` was renamed to `CLOUD_INIT_SOURCE` before the testing
framework ever landed, but I did not mirror that change in .travis.yml
before it landed. This addresses that.
|
|
This introduces the "ci" mark, used to indicate a test which should run
as part of our CI integration testing run and the integration-tests-ci
tox environment, which runs only those tests. Travis has been adjusted
to use this tox environment.
(All current module tests have been marked with the "ci" mark, but the
one bug test that we have has not.)
|
|
Add a script in travis to output a dot every 10 minute during
and integration test run to prevent travis timeout.
Co-authored-by: Rick Harding <rharding@mitechie.com>
|
|
This reverts commit f72d0cb7a03cc311700ea8795edf2454172c7414.
A new release of lxd has been released to the stable channel, which
includes a fix for the issue we were previously working around.
|
|
The latest lxd 4.7 snap causes failures; while we're diagnosing those
and addressing the issues (either upstream or in our code), pin at lxd
4.6 so we can continue to land PRs in cloud-init trunk.
|
|
This is implemented as a copy/paste of the `citest` integration testing
script: the two are not intended to co-exist long-term, so it isn't
worth further complicating an already complex part of our Travis
configuration for short-term code reuse.
The two changes from the `citest` definition: the test framework
executed on the last line of `script`, and it is given a `name` so we
can easily ignore failures.
|
|
We have doc8 configured, so we should use it to gate documentation
changes.
|
|
test using it (#461)
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.
|
|
My previous testing was insufficient: there is a branch of testing that
requires mk-sbuild, which is shipped in ubuntu-dev-tools itself.
|
|
We build in a schroot using sbuild, so we don't need Build-Depends
installed in the host; save some time (and manual maintenance when
Build-Depends change) by dropping their installation and skipping the
check for them when calling `bddeb`. We _do_ require debhelper to be
installed to build the source package, so ensure it is installed.
Additionally, while I was here, replace ubuntu-dev-tools with
devscripts; we don't need everything that ubuntu-dev-tools pulls in.
|
|
Prior to this change, the process of tarring up would mean that Travis
would always detect that the cache had changed, and we would incur ~30s
of packing/transferring at the end of every build.
Instead, we now check if there was any change to the installed contents
of the schroot, and only generate a new tarball if there were changes.
|
|
This makes us more robust, as our caching won't start breaking if other
parts of the Travis build change directory for us.
|
|
Prior to this change, we would debootstrap for every single integration
test run in Travis. This changes that, so we will store the chroot
created by debootstrap in Travis' cache, and use it if available. This
saves 2-3 minutes, or ~1/3rd of the integration test run time (which is
our longest run).
|
|
Instead of running pycodestyle and pyflakes seperately, use flake8 to
get the benefits of pyflakes and also stylistic checks as well as the
ability to configure the settings for the project.
|
|
|
|
This ensures that Travis will not kill our tests if fetching images is
taking a long time.
In implementation terms, this introduces a context manager which will
spin up a multiprocessing.Process in the background and print a dot to
stdout every 10 seconds. The process is terminated when the context
manager exits.
This also drop the use of travis_wait, which was being used to work
around this issue.
|
|
As we only look at these logs when there's an error, and lintian
failures don't cause the package build to error out, we never examine
this lintian output. Let's save ourselves some CI time by skipping it.
(We aren't lintian clean, otherwise a better change here would be to
make lintian warnings cause the package build to fail.)
|
|
cloud-images.ubuntu.com can sometimes be under heavy load; caching the
images helps avoid that affecting our build times (or causing build
failures entirely).
|
|
The integration test doesn't work against the ubuntu/* branches because
it uses the tooling designed to work against master. This means that
ubuntu/* branches always report failures in Travis, which doesn't give
us any signal.
|
|
We're seeing CI failures currently because a LXD image takes more than
10 minutes to download if the transatlantic link to Canonical's DC is
heavily contested.
This uses a helper provided by Travis[0] to avoid cancellation due to
lack of output for 30 minutes, which should be sufficient to download an
image even at the lowest speeds we've been seeing.
[0] https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
|
|
Co-authored-by: Chad Smith <chad.smith@canonical.com>
|
|
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
|
|
|
|
Specifically, drop it from the default list of environments that tox
will run, and from Travis.
(We retain the configuration in tox.ini for now, for any remaining
Python 2.7 needs.)
|
|
This makes it easier to debug differences in test behaviour between
Travis and local developer environments.
|
|
Until we have a clear issue with CI throughput, let's make sure that
we're testing master.
This reverts commit 21967a2dedc781e05cf62c80fb730d0ed5973c8b.
|
|
|
|
This captures the CI testing that is currently performed by the Ubuntu
Server Jenkins instance into a Travis configuration, which is part of
the migration of cloud-init code hosting from Launchpad to GitHub.
|
