Add Github Actions Workflow to build and (unit-)test Audiveris

[PeterGreth]

The workflow already includes loading of trained tesseract ocr data for future integration tests.

Feedback welcome!

[hbitteur]

@PeterGreth

Sorry for this late answer, I was away from my laptop the last couple of weeks.

Could you modify your PR so that we can merge it into "development" branch. Because we don't develop in "master" but in "development". See our Wiki article.

This being said, I'm not familiar with "GitHub Actions workflow". I'm right now googling on it, but perhaps you could shed your own light on this?

[PeterGreth]

Hi @hbitteur, I fixed the target branch.

• "Github Actions" are a way of executing tasks automatically. You can see it as the Github built-in alternative to Jenkins.
• A "workflow" is one such task that is executed automatically. It can be triggered by certain actions.
  • I've added a single workflow (build-and-test.yml) that is called "Build & Test Audiveris"
  • It is triggered whenever commits are pushed to any branch
• A workflow consists of one or many "jobs" that run in parallel on a specific runner environment
  • The added workflow contains only a single job called "build-and-test" that runs on Ubuntu (we could also change it to Windows)
• A job consists of several "steps" that are executed sequentially. These can either be shell scripts that are executed or pre-defined "actions"
  • The added job consists of 6 steps:
    1. The code is checked out. When code is pushed to a branch, the code from that branch is checked out.
    2. Java 17 is installed
    3. Tessdata files are restored from a previous run (see next step)
    4. If the previous step didn't restore Tessdata files from a previous run, those files are downloaded initially. This uses the custom install-tessdata.sh file to download the Tessdata files in english and german
    5. Now we have everything we need to build Audiveris. That is done using the gradle-build-action. Test execution is prevented here
    6. After a successful build, the tests are executed.

The whole workflow will fail if any step (e.g. build or test execution) fails. This can be used to easily see if some functionality broke in a commit. That might especially be useful for regression tests (#563 )

You can see what it looks like on my fork of the repository: https://github.com/PeterGreth/audiveris/actions/workflows/build-and-test.yml

• The main page shows all recent workflow executions (blue: commit that triggered the execution, red: branch on which the commit was pushed)
  
• If you navigate into the execution, you see the executed jobs (here only one in blue)
  
• If you navigate into the job, you see all the steps executed and their output
  

You not only see the executions on that page, but also on every commit and in every PR (see this PR on my fork):

I hope that helps. Feel free to ask if anything is unclear

[hbitteur]

@PeterGreth
I just merged your PR, so that we can start using it in our developments.

Keep in mind that the current Audiveris unit tests are just that: UNIT tests. In other words, they are far from being integration tests. I remember we had a similar discussion last year, about the "number of recognized items" as a quality measurement.

But thanks to your work, we now have a framework in place. Let's try to use it as efficiently as possible.

Reading your PR content, I noticed (please correct me if I'm wrong):

• It seems to be restricted to Linux environment. Could it be extended to Windows?
• I personally use Cygwin under Windows, hence some unix-like stuff like "wget" is readily available. This may not be the case for plain Windows developers.
• Could we avoid hard-coded constants in the build-and-test.yml file? For example: TESSDATA_PREFIX, TESSDATA_TAG, Java version. I'd prefer we put these in our build.gradle file if at all possible.
• You download ENG and DEU languages and not FRA or ITA. Here again, I'd prefer some definition in build.gradle file.

Thanks,
/Hervé