How to test with the latest Virtualmin code from Git? (CI)

There is a lag between development on

And what is released

This is explained here: and it makes sense.

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?

Similarly, I would like to automate testing for WikiSuite (which leverages the Virtualmin installer at

Is there a testing suite for Virtualmin? I would like to run it periodically on various distros to make sure all is still working. is at 7.1.2 but is at 7.1.0 and it would be great to detect issues before the code hits the main repos.



If you are serious about helping out, first off that’s awesome!

Next, let me tag this with @staff so it gets viewed by one of the core developers who can most definitely give you the info you’re looking for.

1 Like

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 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.

1 Like

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…

1 Like

This is beautiful:

1 Like

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:

webmin patch virtual-server 5f607e108aa7d65ed5200e451b.patch


webmin patch apache 8211f7abf9a5cab4d560b288c0.patch

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 instance to protect the signing key when used with GitHub Actions.

On a fresh install of Virtualmin:
root@:/# virtualmin functional-test
Command was not found

Agreed. It will be for experiments, and once we feel more proficient, we can use for low volume development servers.

I think you could just go:


This would be really nice.

We implemented a patching mechanism like this for Tiki Manager and it’s very helpful for advanced testers like nekohayo to confirm fixes before the releases. But it can get messy when multiple patches are applied, so I wouldn’t recommend for long-term patch management.

Although, virtualmin functional-test works for me just fine too!

Weird that I don’t have it

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 so we could replicate on

Well, apparently that library file isn’t included to the production package.

1 Like

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.

1 Like

“This set of changes (…) makes any merge to the master branch build devel packages and publish them to the new devel repository.” Source:

More relevant info:

We see some test examples here:

This is very exciting!

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 :smile:

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).

1 Like

I always setup my development environments without updating the shebang. Instead, I just created a symbolic link:

ln -s /usr/bin/perl /usr/local/bin/perl
1 Like