we have a build server, and we control it over IDE scripting. It’s integerated into our CI/CD Pipeline and is called over Gitlab runners.
This runs okayish, but has some weaknesses we want to get rid of, so I have some questions:
Is it possible to have a “headless” IDE version? Where only the compiler works, not the UI or so?
Can one develop a CLI for controlling the IDE more than the clunky scripting commands and open arguments?
To build a project, you have to sign into Xojo with your account, is that automatable?
When a build is complete, is there a way to determine that? Currently the job, which tells the IDE to open, waits two minutes and the job which makes the IDE build the app has to wait one hour. It fetches then until the new version is in the right folder and continues.
What we have in mind:
Building a docker image with the current IDE in it, Git and other stuff, running on a Linux.
When building, it shall create a new job or Pod in our Kubernetes cluster, start the server, run the IDE, login with our account and build the latest version which is pulled over Git.
After the build we want to kill the docker container.
Why we want to change this:
because to have full automated CI/CD pipeline we have to have an always-on computer.
everytime something on the computer changes a bit, the pipeline could break and we have to fix it manually
everytime the pipeline fails, because of reasons, we have to reset some things on the build server, like closing xojo manually and so
running these steps on our Kubernetes cluster gives the ability to put a huge load of cpu into the build process to speed it up (it takes like 20-30 Minutes currently to build the app).
Has one of you some recommendations, is there a way to achieve these changes?
No. And just in case you are not aware: This is the top 5th request in Feedback:
<https://xojo.com/issue/3215> - 3215 - Allow compilation using the command-line
Until then we’re in a similar situation, using what’s available now. Which is a mix of Shell/Commandline Scripts, using the IDE Communicator. And some hacks and workarounds, e.g. to make sure there’s only 1 build running at a time, always closing (forced if required) the IDE, so that the next build will run, …
I think to remember that there are a couple of Build Automation videos available from Xojo’s XDC sessions that may cover some aspects.
You did find the IDECommunicator project?
You can modify it, but we just use it to run via shell class from one of our tools to run a little Xojo script to build. The script prints the build result as JSON, so we can read it.
A command line compiler would still be very welcome!
FWIW, in summer 2015, I converted Xojo from a manual build process to one that’s completely automatic. Yes, we have to have an always-on machine.
Having a hard time thinking about what could change on a system that would cause your pipelines to break. We’ve got ~40 pipelines running on macOS, Windows, Linux and Raspberry Pi and the biggest thing that gets us is when SSL certs change. Honestly, it’s usually it’s GoCD updates that get us into trouble.
Check your build system and see if they’ve got an “execute on failure” option and have it run a script to kill Xojo and do other cleanup work.
Oh I wish it was that short for us. From when we press go, the IDE takes 3 hrs to build all three platforms.
Then you know that this could be annoying.
In our case it is so, that we run the pipeline several times on some days. We live the continous delivery approach very much. Additionally, building the Docker image after building the executable, all the test before and after and the push to the registry and so on also takes time.
Thats why we want to put the full power of 7 steong nodes in the build process. (I know, Xojo is singlecore, but the other tools we use in the build chain aren’t)
It doesn’t happen often though, but sometimes and thats when it gets annoying. Gitlab sometimes makes nonsense, or the build machine decides to stop working, sometimes the certificates produces odd things, or well, simply the IDE freezes randomly or crashes or so. (if it crashes, we don’t need to close it though).
I just asked, because the current way is not really convenient, you know? And having a dedicated machine in the office feels also just outdated.
Right, so for today’s nightly build the Frameworks took ~30 minutes each, but they build concurrently.
The IDEs took ~2 hrs and 20 minutes. That includes all three builds in 64-bit with optimization set to Aggressive, notarization of the mac build and then upload to the various places takes about 10 minutes.
In addition to that Installers take about 30 minutes (not included in my 3hr estimate above).
Good to know. Then it would be even better if could compile in the cloud.
Sure, I am not complaining about Xojo. I just want to improve our pipelines and Xojo is one part of it.
Handleing the failure of the build process could be improved in our case though.
But, why don’t you develop a CLI based Xojo compiler? Maybe as an payed addon. The ability to compile an application in the cloud is not really a “nice-to-have” anymore. I don’t know any other serous programming tool where the apps can not be built in cloud environments.
I mean, the current situation is okay, I don’t complain as I said, but it could so much better.
It is possible to write Xojo desktop projects to accept command line parameters. Maybe Xojo Inc. could do that, take a parameter like /build and the path to a project to open it and build it without showing the GUI.
You could always have the build machine in the cloud on a vm somewhere, no real need to have the physical hardware for something that needs no physical interaction, but then its electricity/depreciation vs vm costs.
It’s been talked about for a long time, 2008 in feedback <https://xojo.com/issue/3215>. As far as I can recall, its a licencing issue that Xojo cannot figure out, if someone can build a text project in a single location, what is stopping 10 people working on the project and only having one build licence where Xojo would lose 9 other ide sales? If you can figure out this issue, they might look into it.