CI with GitHub hosted runners

With xvfb-run make -C ./.build -j2 all V=1:

/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'polar', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'mesh', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'plot3', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'extended', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'precisiondate', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'gplot', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'grid', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'spmatrix', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'spchol', 'eps');"
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'spcholperm', 'eps');"
warning: using the gnuplot graphics toolkit is discouraged

The gnuplot graphics toolkit is not actively maintained and has a number
of limitations that are ulikely to be fixed.  Communication with gnuplot
uses a one-directional pipe and limited information is passed back to the
Octave interpreter so most changes made interactively in the plot window
will not be reflected in the graphics properties managed by Octave.  For
example, if the plot window is closed with a mouse click, Octave will not
be notified and will not update it's internal list of open figure windows.
We recommend using the qt toolkit instead.
/bin/bash run-octave --norc --silent --no-history --path /home/runner/work/octave/octave/.build/../doc/interpreter/ --eval "splineimages ('doc/interpreter/', 'splinefit1', 'eps');"
make[2]: *** [Makefile:31931: doc/interpreter/spchol.eps] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/runner/work/octave/octave/.build'
make[1]: *** [Makefile:27996: all-recursive] Error 1
make[1]: Leaving directory '/home/runner/work/octave/octave/.build'
make: *** [Makefile:11422: all] Error 2
make: Leaving directory '/home/runner/work/octave/octave/.build'
Error: Process completed with exit code 2.

I guess Ubuntu 18 is old and has an old xvfb-run that still uses “-a”.
I wonder now that something (OOM killer?) kills xvfb server.

Here they explain why you may need “-a” option:
http://elementalselenium.com/tips/38-headless
(See “Running Concurrent Builds”)

With two parallel jobs, it looks like there is still one other image successfully printed (with xfvb) after one job failed. I’d guess that means that xvfb was not a victim of the OOM killer. But I’m not sure.

I’ve reverted the parallel make, and the jobs finished successfully. Does xvfb have issues if two processes request to use the virtual frame buffer too close to each other?

Is there a way to have Octave build with parallel jobs but the documentation build with ‘-j1’?

I tried xvfb-run make -j32 with and w/o any options (-d or -a) and I cannot crash it on my workstation (CentOS 8).
Could you crash it on your workstation/laptop?

I couldn’t cause the issue on my local system either.
I don’t know how xvfb works under the hood. So the following might not be sensible: My local system isn’t actually headless. So even if the xvfb should fail to provide a display for some reason, there is still a physical display to connect to. Maybe that prevents the crash that occurs on the headless runners.

I pushed the last version of the CI rule to the default branch here:
octave: def7cbcf85ed (gnu.org)

Let’s see if the GitHub mirror will pick it up.

The GitHub actions seem to be running ok now.
There are currently two “actions” defined in the default branch of Octave’s repository: “make” and “CodeQL”.

The “make” action is configured to run each time a change is pushed to the repository. It builds Octave on Ubuntu 18.04 and 20.04 with gcc and clang and on macOS 10.15 with clang. It also runs the test suite in all of these combinations.
This seems to work also with forks of the Octave repository on GitHub.

The results and logs can be found on the Actions panel on GitHub:
Actions · gnu-octave/octave (github.com)
It looks like, the logs can only be accessed while logged in to GitHub.

Tests are marked as green if compilation succeeded.
IIUC, actions can either succeed or fail. There doesn’t seem to be a warning state. Also one failing job in the “matrix” seems to cancel other running jobs. So for the time being, test suite errors are not taken into account for the final run result. (Also, there isn’t any logic yet that would analyze the test results.)

The “CodeQL” action is currently configured to run twice a week (on Monday and Thursday at 16:30 UTC). It runs some static code analysis tools provided by GitHub. See also: Finding security vulnerabilities and errors in your code - GitHub Docs
Once the action has successfully run at least one time (which hasn’t happened yet), the analysis results should be available on the Security panel: Code scanning alerts · gnu-octave/octave (github.com)

I hope also other people will find this helpful.

1 Like

As a side note: Many projects decided to rename their main git branch from “master” to something more sensitive.
Would that be possible for our GitHub mirror, too?
Maybe we could use “default” like we do in the Mercurial repository?

@mmuetzel good point, I can work on it later this week. Reminder is set.

1 Like

FWIW, I’m pushing both default and main branch names to my mirror for convenience, they always point to the same ref.

Apparently a CodeQL run has completed

Uploading sarif files: ["/home/runner/work/octave/results/cpp-builtin.sarif"]

But it is not clear to me how to see the results.

The link in the message above works for me. Maybe it is necessary to be logged in again?

I logged in and I got 404 page.

@dasergatskov you are not a member of the “gnu-octave” organization, right? Maybe this is the reason you cannot see the results? I can see them as well :thinking:

@dasergatskov: I sent you an invitation to “gnu-octave” on GitHub. Can you see the results if you accept it?

Yes it works now. Thanks.

Done :white_check_mark:

1 Like

It looks like the GitHub mirror stopped updating automatically. Maybe the commands that do the syncing need to be adapted?

No change without regret :sweat_smile: There was indeed a flaw left to fix. Now it should be back to “normal”.