[WIP] Add tests and Travis CI config

[ismaelgv]

In this PR, there are several additions related to the test discussion in #708:

• Create Docker image to run tests in a clean environment.
• Add manual installation and package operation separated tests.
• Add .travis.yml configuration.

I've tested this workflow in my fork and it seems to work quite fine. Obviously, you need to activate Travis CI for this project.

Basically, we generate a local Docker image from base/devel called arch-pacaur using tests/image/Dockerfile. This image contains all pacaur dependencies, including cower. We use arch-pacaur image to run two types of tests:

• Manual installation (tests/test_install.sh - must be run with sudo): follow steps to install pacaur shown in its PKGBUILD except man generation/install.
• Package operations (tests/test_packages.sh): test system updating, package installation and removal.

I've tried to develop this test workflow as flexible and extensible as possible. The idea is adding more test eventually.

---

Note 1: Docker image is generated before each test since it is using a Travis test matrix. Test matrix is used to run every test in parallel. It does not takes long to build Docker image anyways (~1 minute and 30 secs).

Note 2: These tests have been developed to be run in the Docker image, may cause unexpected results if they are ran in an actual system.

[rmarquis]

Thanks for digging into this.

follow steps to install pacaur shown in its PKGBUILD except man generation/install.

What is the rational here, if I may ask? Some issue with Perl?

[ismaelgv]

Just work in progress. I can add Perl to the Docker image since pod2man is needed to generate man files. I am traveling now but I will fix it ASAP. El 8 dic. 2017 10:53, "Remy Marquis" <[email protected]> escribió:

…

Thanks for digging into this. follow steps to install pacaur shown in its PKGBUILD except man generation/install. What is the rational here, if I may ask? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIFd-kDKm331Pv6LN1TCMgGY4t4Kjctmks5s-QcsgaJpZM4Q5Ztv> .

[rmarquis]

In that case, wouldn't be easier and more logical to use the pacaur PKGBUILD + makpekg -sri directly instead of duplicating its content? This way, we could ensure the official way of installing is also done on docker. The (pacaur-git) PKGBUILD would obviously need to be stored in the git repo.

I guess even hosting the PKGBUILD of the stable version would make sense.

[ismaelgv]

The problem here would be testing changes in non-master branches, PRs, etc. We would need to generate/change PKGBUILDs during the test to point to the commit. Definitely, it is feasible but not sure if offers any advantage. In any case, I think it is a nice idea to test installation of pacaur and pacaur-git in a clean environment. We can already do that in the Docker image. However, I think this is a different kind of automated testing and should be separated from the CI of the repo, or at least not triggered by every change. We could test pacaur-git only in master branch changes and pacaur in tagged releases. El 8 dic. 2017 18:41, "Remy Marquis" <[email protected]> escribió:

…

In that case, wouldn't be easier and more logical to use the pacaur PKGBUILD + makpekg -sri directly instead of duplicating its content? This way, we could ensure the official way of installing is also done on docker. The (pacaur-git) PKGBUILD would obviously need to be stored in the git repo. I guess even hosting the PKGBUILD of the stable version would make sense. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#784 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIFd-jeEyzUkkLIB9OZQg-IhmRzNDk2Uks5s-XS-gaJpZM4Q5Ztv> .

[rmarquis]

The problem here would be testing changes in non-master branches, PRs, etc.
We would need to generate/change PKGBUILDs during the test to point to the
commit. Definitely, it is feasible but not sure if offers any advantage.

Good point. In that case, here is another proposal:

Move the PKGBUILDs content to a buildsystem (make install or similar). This way, the installation process would be entirely handled in the repo for all branches without duplication in the PKGBUILDs.

[ismaelgv]

I have created a simple Makefile that works pretty well in combination with CI. I suppose you could use make and make install in the PKGBUILD.

[rmarquis]

I suppose you could use make and make install in the PKGBUILD.

Yes, that is the idea.

[ismaelgv]

I've added DESTDIR and PREFIX to the Makefile. PREFIX is set to /usr/local as GNU Make documentation suggest, and DESTDIR is empty by default. In the PKGBUILD, you need to change these variables to install files:

make install DESTDIR=$pkgdir PREFIX=/usr

I've installed pacaur with this PKGBUILD pointing to my ci-tests branch, and everything seems fine.

[rmarquis]

Reworked the Makefile, based on your work. Thanks!
As discussed in #708, starting from scratch might be a better solution than doing incremental changes, as the current code is so closely tied togother (ie, monolithic spaghetti monster). At the same time, I'm still wondering if a new repo would be a better solution on the long run.

[ismaelgv]

Even if you start from scratch you can use .travis.yml and Dockerfile of this PR. It will not do any harm to the final user to got some tests right now, independendently of future massive overhaul.

I have removed Makefile conflict from this PR, and now there is only:

• Travis CI configuration.
• arch-pacaur Docker image.
• Basic package tests.