[arch-projects] [dbscripts] [PATCH 1/2] Make tests much more portable and usable
Using 'sudo' in a test? Not on my machine, I don't care how secure it
should be, it is totally unnecessary, not to mention the annoyance of
password prompts, needing the chroot setups, etc. Instead, use makepkg
directly along with some very vanilla makepkg.conf config files to do
the work. This makes for a more reproducable environment as far as
makepkg settings goes.
Also adjust the package building code in common.inc to be a bit more
straightforward. Remove the need for three seperate loops, and only ever
copy packages in one direction (from the local test directory to the
/dev/shm/ staging area).
With these changes, I didn't have too many problems running the test
suite locally on my box after cloning the repository.
Signed-off-by: Dan McGee
Precondition: trunk/ directory never has any subdirectories. This is
true across our entire svn-packages repository, although I did not check
svn-community. The following command was used:
find -mindepth 3 -type d ! -wholename '*/.svn*' -wholename *trunk*
This should really help a variety of things- reduce the number of
commits, reduce the number of emails to arch-commits, make mass package
moves faster, etc.
The entire dbscripts test suite still passes after this change.
Signed-off-by: Dan McGee
On Tue, 28 Jun 2011 21:58:14 -0500, Dan McGee wrote:
Using 'sudo' in a test? Not on my machine, I don't care how secure it should be, it is totally unnecessary, not to mention the annoyance of password prompts, needing the chroot setups, etc. Instead, use makepkg directly along with some very vanilla makepkg.conf config files to do the work. This makes for a more reproducable environment as far as makepkg settings goes.
I prefer using devtools here instead of duplicating tools. This is only a test suite and packages need to be built only once. This way we also make sure we get the same packages as a packager would get. Also your approach would need gcc-multilib to be able to build 32bit packages. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Mon, Jul 25, 2011 at 1:48 PM, Pierre Schmitz
On Tue, 28 Jun 2011 21:58:14 -0500, Dan McGee wrote:
Using 'sudo' in a test? Not on my machine, I don't care how secure it should be, it is totally unnecessary, not to mention the annoyance of password prompts, needing the chroot setups, etc. Instead, use makepkg directly along with some very vanilla makepkg.conf config files to do the work. This makes for a more reproducable environment as far as makepkg settings goes.
I prefer using devtools here instead of duplicating tools. This is only a test suite and packages need to be built only once. What tools are we duplicating?
If the tests aren't self contained, they don't get run. It took me an hour or more to get these running, and that is straight up unacceptable. I will *not* ever give a script sudo access on my machine. Ever. Nor will most other people writing improvements to these tests and scripts.
This way we also make sure we get the same packages as a packager would get.
Also your approach would need gcc-multilib to be able to build 32bit packages. Well for starters your test suite won't even run on x86 because of
The same as makepkg? I don't understand at all what you mean by this and how using makepkg directly is not the same as a packager would get (if it isn't, then devtools is busted, and we aren't attempting to test devtools here). this, and the fact that you try to build 64 bit packages. But more importantly, where does gcc-multilib even come into play here? You aren't even building a real package, and there is no source code!
-- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (3)
-
Dan McGee
-
Dan McGee
-
Pierre Schmitz