Martin Pitt <martin(a)piware.de> writes:
Stef Walter [2017-01-04 16:56 +0100]:
> My question is whether you've tried 'vagrant up' in a cockpit git
> checkout ... and whether that solves the same issue ... or is
> hopelessly broken :D
[...]
The currently specified RAM size can't possibly have worked anytime
recent for running the tests (it needs about 6 GiB RAM, 1 GiB will
fall over really fast), lacks all of the build/test deps, and uses
F24, so I guess this has only been used to run cockpit itself, not for
running any of its tests?
Yes, correct. It's intended for people who want to hack on the
HTML/CSS/JavaScript parts only.
Just to share, my setup is like this:
- I have a number of development VMs for various OSes that I create
manually and ad-hoc with virt-manager. I don't have to recreate them
often, if ever. They usually stick around until I notice that I
don't use them anymore and then they get deleted. They typically
have 8 GiB disk and 2 GiB memory.
- I mount my $HOME into those VMs via NFS and then ssh into them to run
"make" etc. Actually, I just run "f25 make ..." from inside
Emacs
where the "f25" script does the necessary ssh and changes directory
appropriately, so from Emacs, this feels just like local compilation.
- NFS is configured as "async", this is crucial for performance.
- Obviously, all the build deps are installed in the dev VMs, but not
on my laptop.
- I run the unit tests in those development VMs.
- I have the .local/share/config -> .../cockpit/dist symlink in those
VMs, and my edit-compile-run cycle is
- edit
- run "make" (two keystrokes in Emacs), wait a few seconds
- [ correct errors and warnings ]
- reload browser
For some time I was runing "webpack --watch" which would save the
"make" step, but then Emacs doesn't see the errors and warnings, and
it was also a bit flaky and two keystrokes are not something I need
to optimize away. :)
"make install" isn't much slower than "make", so I could do
that and
avoid the symlink, but that would enable the caching features of
Cockpit and instead of just reloading the browser, I would have to
logout and in again for every change.
- I usually only load the iframe that I am working on into the
browser. This makes reloading a bit faster.
- When working on Storaged, NetworkManager, etc, I also do that in the
dev VMs by installing them from source and later reinstalling the
stock version. Works well enough.
- I manually add disks and network interfaces to the dev VMs to play
with the storage and networking components of Cockpit.
- I run the integration tests on my bare metal laptop. They have few
dependencies and do all their destructive work inside their own VMs,
so there doesn't seem to be an advantage to running them inside yet
another VM. I occasionally use virt-manager to access to console of
a test machine for debugging tests that break the network, for
example.