Github Actions + CI

[jelmd]

Hi all,

just enabled CI via Github Actions (GHA) and append it to the branch settings as required. Basically it does the same as Travis-CI (TCI) - so sooner or later GHA or TCI should be disabled.

Basic concept: The pendant to .travis.yml is .github/workflows/ci.yml. Each time the repo receives an event from somewhere, the *.yml files in .github/workflows/ get scanned and if the event matches the on: clause in a file, the related workflow gets started (could be more than 1).

Unfortunately there are limits for GHA as well. What I've found so far is mentioned at the top of ci.yml (but sometimes docs are not clear, obviously outdated and sometimes simply buggy, so YMMV). Most important limit is IMHO 2000 min/month. Lets see, whether we hit it. If so, we have still an option: we can self-host action runners (a.k.a. containers) as needed. However, to get them fool proof/safe, it certainly needs much more work (github recommends to use it for private repos, only) and thus I prefer to find out first, how far we can get without them.

Takeaway is: Please think twice before committing/pushing to a PR - unless canceled every push/commit takes about 90..100 min (if stack,yaml gets changed: + ~20 min).

Current status of [running|run] actions can be found via the Actions tab on the top of the WebUI.

If you have any questions about it, feel free to ask :)

Have fun,
jel.

[tillmo]

Hi @jelmd,
many thanks! Is there a time limit for jobs? @eugenk has split the CI tests into several jobs because of such a limit, with the effect of a much larger overall time.

[jelmd]

Limits I found are at the top of .github/workflows/ci.yml.

So per job the docs say max. 6 h (but I think the real countdown is 24 h) - no problem. Usually the doc generating job takes the longest time (~ 20 min but depends on the HW. I've seen 2.6 and 2.8 GHz CPUs so far). Per workflow the limit is 3 days, so nothing to worry about.

BTW: You can click on the https://github.com/spechub/Hets/actions tab and there on the desired "run" to see the execution time overview (and details if you click on the related box). I made it the same way as I did for travis-ci, i.e. the jobs get run side-by-side if possible and re-use the artifacts from previous jobs .

So the whole workflow goes through usually within ~ 1 + 20 + 14 =~ 35 min instead of 90 + 25 =~ 115 min (IIRC the limit on TCI is 120 min/workflow and this screwed up the tests when run on a little bit slower HW, yepp).

[jelmd]

BTW: Just checked. It seems, that make check now needs OWL_TOOLS as well. Is this correct? Or is it just a duplicated run of ./test/hets-lib-check.sh (what gets run in job Test Hets-lib?). Should one or the other be removed?