rmarquis / pacaur

[unmaintained] An AUR helper that minimizes user interaction
https://bbs.archlinux.org/viewtopic.php?pid=1755144#p1755144
ISC License
796 stars 113 forks source link

[WIP] Add tests and Travis CI config #784

Open ismaelgv opened 6 years ago

ismaelgv commented 6 years ago

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

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:

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 commented 6 years ago

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 commented 6 years ago

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" notifications@github.com 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 https://github.com/rmarquis/pacaur/pull/784#issuecomment-350221955, or mute the thread https://github.com/notifications/unsubscribe-auth/AIFd-kDKm331Pv6LN1TCMgGY4t4Kjctmks5s-QcsgaJpZM4Q5Ztv .

rmarquis commented 6 years ago

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 commented 6 years ago

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" notifications@github.com 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 https://github.com/rmarquis/pacaur/pull/784#issuecomment-350325190, or mute the thread https://github.com/notifications/unsubscribe-auth/AIFd-jeEyzUkkLIB9OZQg-IhmRzNDk2Uks5s-XS-gaJpZM4Q5Ztv .

rmarquis commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Yes, that is the idea.

ismaelgv commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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: