I would like my team to participate more to the development process. Testing and fixing bugs at first, and hopefully soon after, adding features and improving the UI. To make progress on this goal, I would like to set up some test servers that use the latest code from Git. This would not be for production projects, but for experiments. Are there repos that have this latest code already?
How to test with the latest Virtualmin code from Git? (Continuous integration)
@marclaporte I have recently made it possible for Webmin, Usermin and Authentic Theme repos using GitHub Actions, i.e. we now build nightly versions of Webmin and Usermin packages with all the latest changes to builds.webmin.dev. It happens every day at night or on specific commit message, i.e. commit message that contains [build] label.
For Virtualmin, Joe was going to make it possible in the future.
However, a long time ago, for my own use I created a Bash sync script, which looks into my local /etc/hosts file, and syncs automatically to all virtual machines (usually local, which names start with debug-), a file that was just saved, or the whole project using my IDE, e.g.:
It is not a problem for me. I can test code on the fly on any Linux OS variant and version in no time. Nevertheless, this is a good option for me, as a developer, and for CI we need the same approach for Virtualmin GPL and Pro packages, i.e. to use GitHub Actions.
So there is a testing suite - you can run virtualmin functional-test to run all the tests locally. The coverage isn’t complete for all functionality, but it’s very good for the API.
That said, you should be careful running the latest checked-in code on a production system, as it may be in an incomplete state that could break existing sites. We don’t generally run all tests until release time…
I think this is the purpose of development (nightly) builds. Even though, I like the idea of having an ability for a user to get a working preview, like in case of Webmin and Usermin nightly packages, it’s important to remember that a nightly build can contain bugs. What I’m afraid of, is that some users will use it in production and then complain.
There is a testing suite - you can run virtualmin functional-test to run all the tests
While this is great for pre-production package, for a nightly it would be an over kill. I think for a nightly it would be enough just to test for syntax errors.
@Jamie, how about we create a new patch sub command for webmin command to easily apply the patch? For example, something like:
Yeah, at some point I realized that it would be better for all to have those built automatically. The only downside is initial setup, as it took me some time to adjust my build scripts and properly configure webmin.dev instance to protect the signing key when used with GitHub Actions.
Yeah, it’s always easier just to apt-get update && apt-get upgrade -y.
Also, I could do CI for Virtualmin, if Joe gives me the green light … because I remember Joe wanted to make GitHub Actions work for Virtualmin on his own.
I also have virtualmin.dev so we could replicate software.virtualmin.com on software.virtualmin.dev …
Yeah, but it should be in the git repository. Be aware though that it makes a LOT of assumptions about the environment and the existence of test data files for validating that cpanel/etc migrations work.
I’ll try to get more modules building automatically via Github Actions this weekend. I ran into some issues where the old repos were getting broken by automated updates, so I rolled it back until I could spend some time figuring out what was going wrong. The publishing scripts for old repos are kinda messy and happen in two places (on the build server and on the actual web server hosting the repos, for historic reasons).
question – for general testing of the virtualmin devel code, can I simply download the zipped code tree (using the green CODE button) from GitHub - virtualmin/virtualmin-gpl: Virtualmin web hosting control panel for Webmin and then unzip it inside of an existing /usr/libexec/webmin/virtual-server/ directory on my Redhat server? Perhaps erasing all contents of /virtual-server/ first? I was not sure if the typical Virtualmin installation or upgrade was simply that, and was fully contained to that subdirectory tree.
I am interested in seeing if some recent commits will fix some issues that have been bugging me
Naturally it would be a bad idea to do this on a production server; I would use a test server for this activity.
Or are there devel RPMs someplace that I can pull down and install for testing?
You’d need to update the Perl path in all the files that have a Perl shebang (or make a link from /usr/local/bin/perl to the location of your actual Perl, which is usually /usr/bin/perl).
There are no devel RPMs currently being auto-produced, but there will be kinda sorta soon (maybe a month or three).
