Have GitHub actions do a build and test

[gcarreno]

Hey Werner,

If you look a any of my Object Pascal repos you'll notice that I have a .github folder with a *.yml file.

That file tells the GitHub virtual machine what to do in order to build and test my apps under various versions of FPC/Lazarus and multi platforms like Windows, Linux and macOS. I'm only doing Windows and Linux because the action I've created to setup the virtual machine isn't prepared for macOS. I have some ideas on how to do it but I need to solve the dependencies issues for the package installation. And also because I would be doing it by feeling in the dark, I'm kinda scared of how many tags I'll need to drop in order to get it done...

I'm aware you didn't write any tests, I can try an muster some of them, but we can have the application being built and then do the tests.

In fact, because the tests are in another app, it would be a good way for me to show you how I setup one.

I'll create a new branch and start with the basics of the GitHub actions. I'll also drop a badge on the README.md file to indicate the build-test state.

I'll then commit it to the repo and wait to see if you agree with it.

This will not touch a line of code in the source folder.

Cheers,
Gus

[wp-xyz]

If you look a any of my Object Pascal repos you'll notice that I have a .github folder with a *.yml file.

That file tells the GitHub virtual machine what to do in order to build and test my apps under various versions of FPC/Lazarus and multi platforms like Windows, Linux and macOS.

How can this be? Can github access my Lazarus installations on my local PC? And I have Linux and macOS in virtual machines (VirtualBox) which must be running.

I'm aware you didn't write any tests,

Corona is driven by the GUI, i.e. by the user, and I have not idea how to write test cases for automated tests when no user is present.

Werner

[gcarreno]

Hey Werner(@wp-xyz )

How can this be? Can github access my Lazarus installations on my local PC?

NOOOO!!!! ABSOLUTLY NOT!!!! HELL NO!!! Don't even go there!!! xD

The virtual machines belong to GitHub. Are in some data centre on the cloud and spin up for your convenience.
GitHub has come up with the GitHub actions thing which is, basically, a Rust or C#(The Runner) program that runs actions which are coded in Javascript.

You create some folders on you project:

$ mkdir -p .github/workflow

You drop as many YAML files there that the Runner reads as config files and it then performs the actions listed inside.
Have a look at

• https://github.com/wp-xyz/corona/blob/add-github-actions/.github/workflows/build-test.yaml

Every time you commit, and according to the rules on your *.yml file, GitHub spins some virtual machines and runs the list of actions in said *.yml files. Of course, one of the, most at the top, actions has to be the one that does a checkout of your repo.

That's what I have on the pipeline once you're ok with this.

I'm also looking into automating Releases with actions, not just the CI/CD* common stuff, but once one performs a git push --tags, the actions build and packages the binaries, then creates the Release, upload the binaries, all automated.

At the moment we can test Lazarus projects with:

• Many Lazarus/FPC combinations from the sourceforge download
• GitHub's virtual machines are currently:
  • Windows 64b with various versions
  • Ubuntu Linux 64b with various versions

GitHub also provides macOS virtual machines, but we can't use them yet due to me being a tad lazy.

I've created an action, called setup-lazarus, that installs a desired version of a Lazarus/FPC bundle. It can also get packages from the OPM(Online Package Manager inside the IDE) site: https://packages.lazarus-ide.org/

Since sourceforge provides *.dmgs for macOS I can make it work, I just have to implement 1 of 2 ways of installing the *.dmg using the command line via a Javascript program, eheheheh
I also need to complete the code that installs from OPM in order to satisfy dependencies and packages with more than one *.lpk. At the moment you have to be mindful of dependencies and it borks out when dealt with many *.lpk.

* Continuous Integration / Continuous Deployment

Corona is driven by the GUI, i.e. by the user, and I have not idea how to write test cases for automated tests when no user is present.

I'll do the basic unit tests that cover you data objects and then we'll discuss the rest. I my self need to do more than unit tests and I need to find out how and I don't want to go into MVC or MVVM or MVVP.

If any of this is not explained to your satisfaction, please ask me anything. I've re-read it many times and I'm aware it's a bit of information overload. I'm also, famously, a tad awful with long winded explanations.

Cheers,
Gus

[wp-xyz]

That all sound very interesting. But:

• corona requires standard Lazarus only. But what if the project relies on special packages which are not contained in the github versions?
• I'll plan soon to introduce in corona the TPolygonSeries that I added to Laz trunk. Then all tests in the yaml file will not compile any more since they require a release version which does not contain TPolygonSeries.
• Compilation with various Lazarus versions is great for a package, but not very useful for an application.
• You say that whenever I do a commit to the master branch the application is compiled by github. What if the compilation fails because it's late at night and I want to continue on the next day, but want to have the current version in the repo. OK - I probably should not push this to the server at all, but what if I want to? Will the push be accepted? I mean: what is happening when a commit fails in the compilations set up in the yaml file?

[gcarreno]

Hey Werner(@wp-xyz),

corona requires standard Lazarus only. But what if the project relies on special packages which are not contained in the github versions?

Here you have some options:

• Drop the package source under a folder and use it from there
• If in the GitHub ecosystem add a git submodule under a folder and use it from there
• If on the OPM (https://packages.lazarus-ide.org/) my action setup-lazarus will take care of it
  • You just have to install it via the OPM you installed on your Lazarus

I'll plan soon to introduce in corona the TPolygonSeries that I added to Laz trunk. Then all tests in the yaml file will not compile any more since they require a release version which does not contain TPolygonSeries.

If TPolygonSeries is inside the repo, then I'm sure that when you commit, no issues will arise.
The yaml file uses lazbuild to compile the app, so if it works on your machine, it works on the GitHub VM.

Compilation with various Lazarus versions is great for a package, but not very useful for an application.

I see your point, and yeah, more useful for a component or a component bundle so it can be used with many version of Lazarus/FPC.
It's also an indication to other programmers that the recent incarnation of the code, at least compiles under the various VM versions.
None the less, it will also catch some error that can escape us for some reason.
And there's the unit tests that I've been promising...

What if the compilation fails because it's late at night and I want to continue on the next day, but want to have the current version in the repo

First of all, if you look at the yaml file, it only runs it's contents on branches: master and releases\*. So if your hacking away on another branch, then nothing happens.
Which you should, cuz, according to convention of many git flows, master is for the stable code and other branches for code fix and new feature exploration.

Secondly, if branch master doesn't compile, the code is untouched and a commit is never denied.
The only thing that happens is that you have a red X on your last commit instead of a green check mark.
You can then access the Actions tab on your repo a go through the logs to see what/why it failed, that's all.
You can also drop a badge on your README.md that will give you a quicker visual indication. If you have a look at laz-JSON-Viewer's README.md, you can see the badge just below the first header.

Cheers,
Gus