Merge lp:~aaron-whitehouse/duplicity/08-docker-local-import into lp:~duplicity-team/duplicity/0.8-series

Proposed by Aaron Whitehouse
Status: Merged
Merged at revision: 1452
Proposed branch: lp:~aaron-whitehouse/duplicity/08-docker-local-import
Merge into: lp:~duplicity-team/duplicity/0.8-series
Diff against target: 420 lines (+99/-144)
8 files modified
AUTHORS (+1/-1)
README-TESTING (+53/-92)
testing/infrastructure/build-duplicity_test.sh (+5/-20)
testing/infrastructure/duplicity_test/Dockerfile (+12/-7)
testing/infrastructure/duplicity_test/Dockerfile-18.04 (+10/-6)
testing/infrastructure/duplicity_test/Dockerfile-18.10 (+6/-6)
testing/infrastructure/duplicity_test/Dockerfile-19.04 (+6/-6)
testing/infrastructure/duplicity_test/Dockerfile-19.10 (+6/-6)
To merge this branch: bzr merge lp:~aaron-whitehouse/duplicity/08-docker-local-import
Reviewer Review Type Date Requested Status
duplicity-team Pending
Review via email: mp+371839@code.launchpad.net

Commit message

* Convert the Docker infrastructure to pull the local branch into duplicity_test. This allows testing the local branch with the known-good Docker environment, even if it has not yet been committed to trunk.
* As a consequence, remove the -r option to build-duplicity_test.sh. This functionality can be achieved by branching that revision before running the script.

Description of the change

* Convert the Docker infrastructure to pull the local branch into duplicity_test. This allows testing the local branch with the known-good Docker environment, even if it has not yet been committed to trunk.
* As a consequence, remove the -r option to build-duplicity_test.sh. This functionality can be achieved by branching that revision before running the script.

We have now spent a lot of time ensuring that the Docker containers work correctly and contain all of the relevant dependencies. We have a steady stream of people struggling to set up their environments correctly to test and we have people propose merges that do not pass all of our tests. We should leverage the Docker container work and make it easy for people to use these to test their work before submitting it for merging. I have personally been using this approach for a little while and find it a much easier way to run tests on my branch.

To post a comment you must log in.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'AUTHORS'
2--- AUTHORS 2018-08-01 15:47:17 +0000
3+++ AUTHORS 2019-08-26 22:23:05 +0000
4@@ -1,7 +1,7 @@
5 Duplicity Authors
6 -----------------
7
8-- Aaron Whitehouse <aaron@whitehouse.kiwi.nz>
9+- Aaron Whitehouse <code@whitehouse.kiwi.nz>
10 - Alexander Zangerl <az@snafu.priv.at>
11 - Andrea Grandi <a.grandi@gmail.com>
12 - Ben Escoto <ben@emerose.org>
13
14=== modified file 'README-TESTING'
15--- README-TESTING 2019-03-10 13:12:26 +0000
16+++ README-TESTING 2019-08-26 22:23:05 +0000
17@@ -1,9 +1,26 @@
18-# Testing duplicty
19+# Testing duplicity
20
21 ## Introduction
22-Duplicity's test concept bases on unit test.
23-All tests are contained in the /testing folder of the main repository.
24-
25+Duplicity's tests are unit tests contained in the /testing folder of the main repository.
26+
27+## Running tests on your branch
28+The recommended approach is to test duplicity using Docker, to ensure that you are running tests in a known-good
29+environment. This also creates additional containers to test backends. You can run tests on your branch as follows:
30+a. Install Docker
31+b. cd [BRANCH FOLDER]/testing/infrastructure/
32+c. ./build-duplicity_test.sh to build the required Docker containers and copy your branch into
33+ the duplicity_test container.
34+d. ./setup.sh to start the containers and open a shell inside your branch folder in duplicity_test.
35+e. cd testing/
36+f. ./run-tests
37+g. When you are finished, exit the Docker container and run ./teardown.sh to delete the containers.
38+
39+Please test your branch using this method and ensure all tests pass before submitting a merge request.
40+
41+The decorator @unittest.expectedFailure can be used to commit a known-failing test case without breaking the test suite,
42+for example to exhibit the behaviour in a bug report before it has been fixed.
43+
44+## Manual testing and running individual tests
45 As to see in the following sketch, there are several levels of testing duplicity and each can be used directly.
46
47 ┌─────────────────────┐
48@@ -11,7 +28,7 @@
49 ├─────────────────────┴────┐
50 │ │
51 │ ┌──────────────────┐ │
52- │ │ tox │ │
53+ │ │ run-tests/tox │ │
54 │ └──────────────────┘ │
55 │ │ │
56 │ ▼ │
57@@ -25,25 +42,28 @@
58 │ └──────────────────┘ │
59 │ │
60 └──────────────────────────┘
61-1. Testing directly using __setup.py__
62-Assuming that your machine has all the required dependencies installed, you can start all the unit tests by simply typing
63-
64-‘setup.py test‘
65-
66-2. Using __tox__
67-Tox is a generic virtualenv management and test command line tool that is used for checking your package installs correctly with different Python versions and interpreters. It
68-runs the tests in each of the environments that are configured in the tox.ini file (see root folder of the repository)
69-
70-Duplicity uses tox to make it easy to test your code against multiple
71-environments. Running tests using the commands above will automatically test
72-code against different supported environments, including the versions of
73-dependencies used by the Launchpad build system.
74-
75-A tox run can be started simply by typing
76+
77+1. Docker container
78+Even if you wish to run tests manually, we recommend that you do this inside the provided Docker container to ensure
79+that you have a clean and reproducible environment with all required dependencies for executing these. Please follow
80+steps a to d of the above section titled "Running tests on your branch".
81+
82+2. Using run-tests
83+The run-tests script mentioned above is a shortcut to running all tests with tox. This is the recommended approach to
84+run tests on your code. We recommend running this within the provided Docker container as mentioned above, but it is
85+possible to run this directly if you have installed all required dependencies (see "Dependencies for testing" below).
86+
87+3. Using tox
88+Tox is a generic virtualenv management and test command line tool that is used for checking your package installs
89+correctly with different Python versions and interpreters. It runs the tests in each of the environments that are
90+configured in the tox.ini file (see root folder of the repository). As mentioned, we recommend this is run inside the
91+provided Docker container.
92+
93+A tox run can be started simply by typing
94
95 ‘tox‘
96
97-from the main duplicity folder.
98+from the main duplicity folder.
99
100 You can run specific tests using:
101 ‘tox -- [test filename][::TestClassName::test_method]‘
102@@ -57,38 +77,22 @@
103
104 Or stack these together, e.g.
105 ‘tox -e py3 -- testing/unit/test_selection.py::MatchingTest::test_tuple_include‘
106-for example if you are working on fixing a bug, but please do a full run-tests
107-before submitting a merge request.
108-
109-Note: some tests require rdiff and pylint to be installed on the system for
110-them to pass.
111-
112-Please run all tests on your branch (run-tests) before proposing a merge, to
113-ensure that all tests pass. The decorator @unittest.expectedFailure can be used
114-to commit a known-failing test case without breaking the test suite, for
115-example to exhibit the behaviour in a bug report before it has been fixed.
116-
117-3. Via a __docker__ image
118-Testing on a developer's machine can be tricky. Testing duplicity requires a set of dependencies being installed and reacts sensitiviely to changes of the local python configuration. In order to make sure that such interactions do not pose any influence on executing the tests, docker is the technology of choice.
119-Along with the tests, a docker image has been created (cf. Dockerfile in root folder of repo) that ensure the following things:
120-- It bases on a clean Ubunut 16.04
121-- It installs all the required packages that are needed for testing
122-- It then branches the repository of duplicty to the folder /duplicty/testing within the docker image
123-- And installs all the required python packages (as defined in the requirements.txt)
124-Therewith, the docker image provides a clean and reproducible environment for executing the tests of duplicty.
125-In order to get hands on the docker image you simply:
126-1) Install Docker on your machine (https://docs.docker.com/engine/installation/)
127-2) Start the image docker run -it dernils/duplicitytest /bin/bash (if you did not use the image before, it will be downloaded automatically)
128-3) At the prompt of the docker image type:
129-‘cd /testing‘
130-‘tox‘
131-to start a run of the test cases.
132+
133+This is helpful, for example, if you are working on fixing a bug, but please do a full run-tests before submitting a
134+merge request.
135+
136+4. Testing directly using __setup.py__
137+Assuming that your machine has all the required dependencies installed, you can start all the unit tests by simply typing
138+
139+‘setup.py test‘
140
141 ## Dependencies for testing
142-If you should prefer to execute the tests locally without using docker, the Dockerfile that is checked into the root folder of the repository contains useful information. It contains a section marked "The following packages are needed for testing duplicity". Within this section all dependencies that need to be installed on a machine to execute the test cases are identified.
143+If you should prefer to execute the tests locally without using Docker, see the Dockerfile in
144+testing/infrastructure/duplicity_test/
145+for requirements to correctly set up your environment.
146
147 ## Working with test coverage
148-Python makes it easy to determine, how well the tests cover the source code.
149+Python makes it easy to determine how well the tests cover the source code.
150
151 You first run the tests __under observation__ of the coverage script:
152 ‘coverage run setup.py test‘
153@@ -96,46 +100,3 @@
154 ‘coverage html --omit="testing/*,/usr/*"‘
155
156 The report will be generated and stored in the folder htmlcov.
157-
158-## The wider picture - supporting containers for testing
159-Testing duplicity invokes backends. The backends are the places where the backup data is actually stored (e.g. an ftp server). In order to have the highest degree of control over the testing process, backends that can be set up locally are also operated in separated docker containers. The whole test infrastructure is shown in the following picture.
160-
161-┌─────────────────────┐ ┌──────────────────────────────────────────┐
162-│docker image │ │docker image │
163-│dernils/duplicitytest│ │dernils/duplicity_testinfrastructure_ssh │
164-├─────────────────────┴────┐ ├──────────────────────────────────────────┴──┐
165-│ │ │ │
166-│ ┌──────────────────┐ │ │ ┌──────────────────┐ │
167-│ │ tox │ │ ┌──┼──▶│ sshd │ │
168-│ └──────────────────┘ │ │ │ └──────────────────┘ │
169-│ │ │ │ │ │
170-│ ▼ │ │ └─────────────────────────────────────────────┘
171-│ ┌──────────────────┐ │ │ ┌──────────────────────────────────────────┐
172-│ │ unittests │ │ │ │docker image │
173-│ └──────────────────┘ │ │ │dernils/duplicity_testinfrastructure_ftp │
174-│ │ │ │ ├──────────────────────────────────────────┴──┐
175-│ ▼ │ │ │ │
176-│ ┌──────────────────┐ │ │ │ ┌──────────────────┐ │
177-│ │ duplicity │◀───┼─┴──┼──▶│ pure-ftpd │ │
178-│ └──────────────────┘ │ │ └──────────────────┘ │
179-│ │ │ │ │
180-└────────────┼─────────────┘ └─────────────────────────────────────────────┘
181- │
182- │
183- │
184- └────────────┐
185- │
186- Internet .─────────┼─────────.
187- _.────' │ `─────.
188- _.─' │ `──.
189- ,' ▼ `.
190- ; ┌──────────────────┐ :
191- : │ Dropbox │ ;
192- ╲ └──────────────────┘ ╱
193- `. ,'
194- `──. _.─'
195- `─────. _.────'
196- `─────────────────'
197-
198-The docker images that contain the test infrastructure are defined in the folder /testing/infrastructure. There is a build script to compile the Dockerfile into actual images (build-duplicitiy-test.sh). However, as all images are also published on the docker hub, it is not necessary to build the images before starting testing. Testing can directly be started by using the script setup.sh. If the required docker images are not yet existing, locally, they will be downloaded by Docker.
199-
200
201=== modified file 'testing/infrastructure/build-duplicity_test.sh'
202--- testing/infrastructure/build-duplicity_test.sh 2019-07-22 19:40:09 +0000
203+++ testing/infrastructure/build-duplicity_test.sh 2019-08-26 22:23:05 +0000
204@@ -23,9 +23,8 @@
205 #
206
207 usage() {
208- echo "Usage: $0 [-d <distro>] [-r <revno>]" 1>&2
209+ echo "Usage: $0 [-d <distro>]" 1>&2
210 echo " - Default distro is 18.04" 1>&2
211- echo " - Default revno is `bzr revno`" 1>&2
212 exit 1;
213 }
214
215@@ -35,20 +34,13 @@
216 DISTRO=18.04
217 fi
218
219-if [ "$REVNO" == "" ]; then
220- REVNO=`bzr revno`
221-fi
222-
223 # possibly override with commandline
224
225-while getopts ":d:r:h" opt; do
226+while getopts ":d:h" opt; do
227 case ${opt} in
228 d )
229 DISTRO=$OPTARG
230 ;;
231- r )
232- REVNO=$OPTARG
233- ;;
234 h )
235 usage
236 ;;
237@@ -66,19 +58,12 @@
238
239 # build duplicity_test
240
241-cd duplicity_test
242-cp -p ../../../requirements.txt .
243-cp -p ../id_rsa .
244-cp -p ../id_rsa.pub .
245-docker build --build-arg REVNO=$REVNO -f Dockerfile-$DISTRO --tag firstprime/duplicity_test .
246-rm requirements.txt
247-rm id_rsa
248-rm id_rsa.pub
249-cd ..
250+cd ../..
251+docker build -f testing/infrastructure/duplicity_test/Dockerfile-$DISTRO --tag firstprime/duplicity_test .
252
253+cd testing/infrastructure/ftp_server
254 # build duplicity_ftp
255
256-cd ftp_server
257 docker build --tag firstprime/duplicity_ftp .
258 cd ..
259
260
261=== modified file 'testing/infrastructure/duplicity_test/Dockerfile'
262--- testing/infrastructure/duplicity_test/Dockerfile 2019-07-22 19:40:09 +0000
263+++ testing/infrastructure/duplicity_test/Dockerfile 2019-08-26 22:23:05 +0000
264@@ -1,6 +1,7 @@
265 # -*- Mode:Python; indent-tabs-mode:nil; tab-width:4 -*-
266 #
267-# Copyright 2017 Nils Tekampe <nils@tekampe.org>
268+# Copyright 2019 Nils Tekampe <nils@tekampe.org>,
269+# Kenneth Loafman <kenneth@loafman.com> and Aaron Whitehouse <code@whitehouse.kiwi.nz>
270 #
271 # This file is part of duplicity.
272 #
273@@ -18,6 +19,10 @@
274 # along with duplicity; if not, write to the Free Software Foundation,
275 # Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
276
277+# This Dockerfile assumes that docker built will be called from the parent
278+# duplicity folder with -f testing/infrastructure/ so that the whole folder
279+# can be copied into the container for testing.
280+
281 FROM ubuntu:18.04
282
283 # Set locale to prevent UTF-8 errors
284@@ -77,15 +82,15 @@
285
286 # Copy a SSH key to the users folder that is used for some test cases
287 USER root
288-COPY ./id_rsa /home/test/.ssh/
289-COPY ./id_rsa.pub /home/test/.ssh/
290+COPY testing/infrastructure/id_rsa /home/test/.ssh/
291+COPY testing/infrastructure/id_rsa.pub /home/test/.ssh/
292 RUN chown -R test:test /home/test/.ssh
293 RUN chmod 400 /home/test/.ssh/id_rsa
294+
295+# Copy the local duplicity folder into the container
296+COPY . duplicity/
297+RUN chown -R test:test duplicity
298 USER test
299
300-# Branch the duplicity repo for testing
301-ARG REVNO=-1
302-RUN bzr branch -r $REVNO lp:duplicity duplicity
303-
304 # Set final workdir to duplicity
305 WORKDIR /home/test/duplicity
306
307=== modified file 'testing/infrastructure/duplicity_test/Dockerfile-18.04'
308--- testing/infrastructure/duplicity_test/Dockerfile-18.04 2019-07-22 19:40:09 +0000
309+++ testing/infrastructure/duplicity_test/Dockerfile-18.04 2019-08-26 22:23:05 +0000
310@@ -18,6 +18,10 @@
311 # along with duplicity; if not, write to the Free Software Foundation,
312 # Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
313
314+# This Dockerfile assumes that docker built will be called from the parent
315+# duplicity folder with -f testing/infrastructure/ so that the whole folder
316+# can be copied into the container for testing.
317+
318 FROM ubuntu:18.04
319
320 # Set locale to prevent UTF-8 errors
321@@ -77,15 +81,15 @@
322
323 # Copy a SSH key to the users folder that is used for some test cases
324 USER root
325-COPY ./id_rsa /home/test/.ssh/
326-COPY ./id_rsa.pub /home/test/.ssh/
327+COPY testing/infrastructure/id_rsa /home/test/.ssh/
328+COPY testing/infrastructure/id_rsa.pub /home/test/.ssh/
329 RUN chown -R test:test /home/test/.ssh
330 RUN chmod 400 /home/test/.ssh/id_rsa
331+
332+# Copy the local duplicity folder into the container
333+COPY . duplicity/
334+RUN chown -R test:test duplicity
335 USER test
336
337-# Branch the duplicity repo for testing
338-ARG REVNO=-1
339-RUN bzr branch -r $REVNO lp:duplicity duplicity
340-
341 # Set final workdir to duplicity
342 WORKDIR /home/test/duplicity
343
344=== modified file 'testing/infrastructure/duplicity_test/Dockerfile-18.10'
345--- testing/infrastructure/duplicity_test/Dockerfile-18.10 2019-07-22 19:40:09 +0000
346+++ testing/infrastructure/duplicity_test/Dockerfile-18.10 2019-08-26 22:23:05 +0000
347@@ -77,15 +77,15 @@
348
349 # Copy a SSH key to the users folder that is used for some test cases
350 USER root
351-COPY ./id_rsa /home/test/.ssh/
352-COPY ./id_rsa.pub /home/test/.ssh/
353+COPY testing/infrastructure/id_rsa /home/test/.ssh/
354+COPY testing/infrastructure/id_rsa.pub /home/test/.ssh/
355 RUN chown -R test:test /home/test/.ssh
356 RUN chmod 400 /home/test/.ssh/id_rsa
357+
358+# Copy the local duplicity folder into the container
359+COPY . duplicity/
360+RUN chown -R test:test duplicity
361 USER test
362
363-# Branch the duplicity repo for testing
364-ARG REVNO=-1
365-RUN bzr branch -r $REVNO lp:duplicity duplicity
366-
367 # Set final workdir to duplicity
368 WORKDIR /home/test/duplicity
369
370=== modified file 'testing/infrastructure/duplicity_test/Dockerfile-19.04'
371--- testing/infrastructure/duplicity_test/Dockerfile-19.04 2019-07-22 19:40:09 +0000
372+++ testing/infrastructure/duplicity_test/Dockerfile-19.04 2019-08-26 22:23:05 +0000
373@@ -75,15 +75,15 @@
374
375 # Copy a SSH key to the users folder that is used for some test cases
376 USER root
377-COPY ./id_rsa /home/test/.ssh/
378-COPY ./id_rsa.pub /home/test/.ssh/
379+COPY testing/infrastructure/id_rsa /home/test/.ssh/
380+COPY testing/infrastructure/id_rsa.pub /home/test/.ssh/
381 RUN chown -R test:test /home/test/.ssh
382 RUN chmod 400 /home/test/.ssh/id_rsa
383+
384+# Copy the local duplicity folder into the container
385+COPY . duplicity/
386+RUN chown -R test:test duplicity
387 USER test
388
389-# Branch the duplicity repo for testing
390-ARG REVNO=-1
391-RUN bzr branch -r $REVNO lp:duplicity duplicity
392-
393 # Set final workdir to duplicity
394 WORKDIR /home/test/duplicity
395
396=== modified file 'testing/infrastructure/duplicity_test/Dockerfile-19.10'
397--- testing/infrastructure/duplicity_test/Dockerfile-19.10 2019-07-22 19:40:09 +0000
398+++ testing/infrastructure/duplicity_test/Dockerfile-19.10 2019-08-26 22:23:05 +0000
399@@ -75,15 +75,15 @@
400
401 # Copy a SSH key to the users folder that is used for some test cases
402 USER root
403-COPY ./id_rsa /home/test/.ssh/
404-COPY ./id_rsa.pub /home/test/.ssh/
405+COPY testing/infrastructure/id_rsa /home/test/.ssh/
406+COPY testing/infrastructure/id_rsa.pub /home/test/.ssh/
407 RUN chown -R test:test /home/test/.ssh
408 RUN chmod 400 /home/test/.ssh/id_rsa
409+
410+# Copy the local duplicity folder into the container
411+COPY . duplicity/
412+RUN chown -R test:test duplicity
413 USER test
414
415-# Branch the duplicity repo for testing
416-ARG REVNO=-1
417-RUN bzr branch -r $REVNO lp:duplicity duplicity
418-
419 # Set final workdir to duplicity
420 WORKDIR /home/test/duplicity

Subscribers

People subscribed via source and target branches