Martin Pitt <[email protected]> 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. _______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
