Running Xojo in Headless Linux CI/CD environments

Hey everyone,

During a recent post, I got talking about how one could run the Linux Xojo IDE on a headless linux server setup. For clarity, In this case, I’m talking about an AWS EC2 Instance running Ubuntu 24.04 LTS with a 2vCPU 8GB configuration.

To get this working, you need a few things:

  1. Xojo (obviously)
  2. A Xojo License (because Xojo requires that for building)
  3. vnc or other vnc-compatible viewer
  4. xvfb (a virtual frame buffer)

Installation of everything you need is pretty simple:

# Make sure your os is up to date
sudo apt-get update -y
sudo apt-get upgrade -y
sudo apt --fix-broken install -y

# Install xvfb & dependencies
sudo apt-get install xvfb -y
sudo apt-get install x11-apps imagemagik -y

# VNC (you'll need this to enter your Xojo license)
sudo apt-get install x11vnc -y

# Xojo Dependencies
sudo apt-get install libgtk-3-0 libsoup-2.4-1 firefox npm weston libgtk2.0-0 libglib2.0-dev libunwind8* glib-2* -y

# Xojo
curl <linux deb Xojo url> > Xojo.deb
sudo dpkg -I Xojo.deb

To do the initial setup, you’ll need to set up a virtual screen and share it using VNC so you can license Xojo:

xvfb :99 -screen 0 1280x1024x24 &
export DISPLAY=:99

x11vnc -display :99 -nopw -forever &

Using an ssh terminal connection, launch Xojo on the machine:

/opt/xojo/Xojo2024r3/Xojo

…and then connect to the “screen”. I use the Screen Sharing.app that comes with macOS, but you could use any VNC-compatible viewer. To connect to VNC on your server, you’ll need to make an ssh tunnel replacing the user and ip address as necessary:

ssh -L 5900:localhost:5900 user@ip.ad.dr.ess -N

Once that’s done, you should be able to open your screen sharing app and connect locally on port 5900.

Once you connect, you will see a very low resolution rendition of Xojo through the shared screen buffer. Since you won’t actually be using Xojo this way on a day-to-day basis, this isn’t a big deal. Just get to the help menu and log into your account to download your Xojo license and then exit Xojo.

Now for the fun part. In your build scripts, whenever you need to build something with Xojo, you’ll need to have it run a few commands:

# start xvfb
xvfb :99 -screen 0 1280x1024x24 &
export DISPLAY=:99

# turn on VNC if you want to be able to watch
x11vnc -display :99 -nopw -forever &
if [ $? -ne 0 ]; then
  echo "x11vnc did not start"
  x11_pid=0
else
  x11_pid=$!
fi

# tell Xojo not to show dialogs
export XOJO_AUTOMATION=1

# launch xojo
/opt/xojo/xojo2024r3/Xojo &
xojo_pid=$!

xojo_project="path/to/your/xojo/project.xojo_project"

# create a build script that opens our file and builds it
cat << EOF > script
// This code is in XojoScript
OpenFile("$(realpath $xojo_project)")

// Other build constants can be found by searching docs for "BuildApp"
dim path as String
// Build the app but don't try to show the file
path = BuildApp(16, false) // 64-bit linux
print path

// Tell the IDE to quit without saving any changes
QuitIDE(False)
EOF

# Use IDE Communicator protocols to send the script to Xojo

# Wait for the IDE to finish
wait $xojo_pid

# kill off the services we started x11vnc and xvfb
if [ $x11_pid -gt 0 ]; then
  kill $x11_pid
fi

if [ $xvfb_pid -gt -1 ]; then
  kill $xvfb_pid
fi

Now as for building other platforms, there’s no reason you should have a problem building for macOS or Windows in a linux environment. You will however need those environments for doing the platform specific things like code signing, installer & package creation as well as notarization on macOS. It may take some experimentation, but you should be able to store the build results as artifacts for later downloading on another machine.

NOTE: When doing this, make sure you are honoring Xojo’s license agreement in terms of how many concurrent installs you have for your licenses.

12 Likes

This is great!

I did, however, expect to see the script include pulling from a git repo before compiling then pushing the builds back to the repo after. That, of course, would require setting up git with your credentials and doing the initial clone.

That is very cool Greg!

I had read that original post and thought your concept was interesting. Glad it could go from concept to reality, seemingly overnight!

Tim

I have just published a repo that has a Xojo IDE Communicator clone that’s written in Go which has a very simple interface:

Usage: xojo-cli -f <command-file> [-s socketPath] [-s timeout]
  -f string
    	The script to run
  -s string
    	The path to the Xojo IDE socket (default "/tmp/XojoIDE")
  -t int
    	The number of seconds to wait for the Xojo IDE to connect (default 30)

In the example I gave above, you would add this line for launching the IDE:

xojo-cli -f ./script -t 120
1 Like

To be honest, I don’t want to be the guy that everyone comes to when my git instructions don’t work in their particular environment. I’m providing a method and a tool to help people who are already familiar with CI/CD to make their lives a little easier.

2 Likes

That depends on your workflow… certainly simple to add.
At least I don’t need a script which checks out a repo (the script would also need to know which branch, whether to create a beta/final release/build, …) - probably not something you want to enter each and every time.

You could of course also combine Greg’s HowTo with : GitHub: jo-tools/xojo-github-actions

Basically: the above example has Xojo installed on macOS. But you could install the GitHub runner on such a Linux VM. So that by pushing to the Repo (or creating a Pull Request, whatever), a build could automatically be triggered and the artefacts pushed.

At least for Windows Builds you could combine this with: GitHub: jo-tools/ats-codesign-innosetup
Creating a (codesigned) Windows Installer could be done on that Linux VM quite easily.

And for those using @Tim_Parnell 's Lifeboat and also using the self-hosted Forgejo
…they could use their Forgejo Runner for build automation, so that by simply pushing to the Git Repo it could trigger a (beta/release) build.

Thanks @Greg_O for this Post - this opens a variety of possibilities which can be combined with other CI/CD examples that already exist.

I guess I should say that I expected some mention of git, not that I expected you to flesh out the implementation. I understand not wanting to be the point of contact for a small part that is only tangentially related to a concept you’re sharing for nothing.

1 Like

It wasn’t that fast. I just needed to write it up. It’s something I created for work so we could move away from the ultra-expensive AWS macOS EC2 instances for Xojo building.

2 Likes

Greg this wonderful stuff. Thanks for sharing.

I, as well as any others, DO appreciate your effort and sharing!

Thanks again Greg
Tim