Update CI, mostly MSYS1 (now using CI tarball instead of checkout)

[GitMensch]

• ubuntu:
  • only run coverage and additional warnings when main ci build works - use its generated tarball
  • trigger MSYS1 build, passing the run-id
• msys1+ubuntu:
  • use "build" instead of "_build" dropped to stay with OCamlPro standard
  • upload config.log after the build - because we may need it to debug build issues
  • always upload the testsuite.log (additional build documentation)
• msys1:
  • drop GC install log and therefore extra prefix
  • building BDB with all relevant patches from MSYS2
  • GMP url changes, building it again for performance reasons
  • using msys-build instead of building Bison (only necessary for GC4)
  • enable NIST85, skipping extra IF106A as this hangs, ignoring failing NIST for now dropped, as upstream fixed that
  • ci cache adjustment:
    • remove split per matrix
    • split per software, enabling smaller updates
  • use CI tarball like for the minimal build
  • job-scoped testuite adjustment (skip/xfail) in the generated script, not the source

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.75%. Comparing base (2c000f5) to head (d84c3ea).
Report is 5 commits behind head on gcos4gnucobol-3.x.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@                  Coverage Diff                  @@
##           gcos4gnucobol-3.x     #186      +/-   ##
=====================================================
- Coverage              77.56%   67.75%   -9.81%     
=====================================================
  Files                     33       33              
  Lines                  60230    60245      +15     
  Branches               15834    15839       +5     
=====================================================
- Hits                   46717    40819    -5898     
- Misses                 13513    13531      +18     
- Partials                   0     5895    +5895     

Flag	Coverage Δ
	67.75% <ø> (-9.81%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[GitMensch]

@lefessan @ddeclerck @nberth So this current version does work (or at least should), but it is a rather complicate setup:

• Ubuntu workflow creates the dist tarball after running initial checks
• it starts the MSYS1 workflow "detached", passing its run it
• the MSYS1 workflow downloads the artifact, then uses it

The biggest downside is, that using this approach the MSYS1 workflow doesn't show up in the PR workflow at all, you can only see it in the "actions" tab.

Options to go on:

1. leave as is, merge (and loose MSYS1 out of sight)
2. make the MSYS1 more complicated, by:

• trigger the second workflow as part of the PR again
• do a minimal checkout to throw away later, get the git sha out of it
• poll the GitHub API to check the status of the "Ubuntu workflow" with the git sha , get its run-id and wait until it completes
• once that happened, fetch the artifact
• handle timeouts in case the "Ubuntu workflow" takes too long to finis

3. integrate the MSYS1 workflow into the Ubuntu workflow, making it look a bit more complicated (and obviously: we should rename it then); this would work as we can set all of build-matrix, runs-on and env on the job scope; this we we can easily wait for the artifact and get it even without a token

I tend to option 3, the only side effects I see are that we can't only run the Ubuntu or MSYS1 jobs anymore then (as far as I know it is always "all of a single workflow"). In theory this could also lead to a workflow timeout, but so far there is nothing we need to be concerned of, timing-wise with that.

[ddeclerck]

As for the MSYS1 workflow : maybe I missed something ; why is it necessary to trigger it from the Ubuntu workflow ?

[GitMensch]

If the workflow is separated then we can only get the CI tarball (MSYS1 is too old to build with the new dependencies in GC 3.3) by knowing the run-id of the job; we can either trigger it from Ubuntu to do so (but this misses the output in PRs.. and anywhere outside the "Action" tab) or do some more complicate API calling with timeout in the MSYS1.

... or we just combine them into one, and save all the struggle...

[ddeclerck]

... or we just combine them into one, and save all the struggle...

That might be a good idea. But considering you already went through the struggle, might as well keep it as you made it.

[GitMensch]

I think I'll give that a shot soonTM, maybe its as easy as I've thought :-)

[GitMensch]

It would be really good to know which of those tests hang under MSYS2.

While CI runs take longer that way it could be reasonable doing an explicit make test first (multi-job), then a non-parallel run of the internal testsuite - and if there are still hanging results check if we see "regular" issues at the same set of tests ?