CI: Compute a job matrix

[Paebbels]

Add a prepare job to detect which MSYS2 environment is needed to be started for a build operation.

Fixes #28338

[Paebbels]

Do you want to get a nice error message in case the job matrix is empty?

I can let the build matrix skip, but what about the 2 remaining jobs?

[striezel]

I can let the build matrix skip, but what about the 2 remaining jobs?

The package-grokker and check jobs are not needed, if no packages are built. Both basically test different aspects of the built packages, but without any packages there is no need to let those jobs run.

[ognevny]

is it possible to put this script in separate file? it seems to be very large for embedding into workflow file

[Paebbels]

The package-grokker and check jobs are not needed, if no packages are built.

OK. I'll add an error message in the "annotations" area and terminate the pipeline by not generating further jobs at all.

Do you like it as: error, warning or info if the result is empty?

Should further checks be integrated like:

• a package/files in a directory were modified, but PKGBUILD was not modified?

---

is it possible to put this script in separate file?
it seems to be very large for embedding into workflow file

There are two options:

• separate Python file
• separate YAML file for the job (GitHub reusable workflow)

I wrote it in the YAML file (despite bad debugging and syntax checking features from editors). because it's a unit and if extracted to a separate YAML file, it can be reused cross-repository. Separate Python files can't be reused (as in GitHub reusable workflows).

If modified to a reusable workflow, it would look like this file:
https://github.com/pyTooling/Actions/blob/dev/.github/workflows/CleanupArtifacts.yml
and instantiation like that:

  IntermediateCleanUp:
    uses: pyTooling/Actions/.github/workflows/CleanupArtifacts.yml@r7
    needs:
      - UnitTestingParams
    with:
      json: ${{ needs.UnitTestingParams.outputs.artifact_names }}
      artifact-json-ids: >-
        codecoverage_sqlite:-*
        unittesting_xml:-*

[ognevny]

not sure we want have reusable thing, in our case it seems to be very local

[Paebbels]

Changes:

• The Python code has been extracted and moved into .ci/ci-prepare.py.
• An error message is created in case of an empty job list.
• A list of modified packages is offered as an additional output parameter.
  => space separated, so it's usable by Bash scripting.
• If list of modified packages is empty, no further jobs are launched.

Error message	2 Architectures

[Paebbels]

@ognevny, @striezel, @lazka any further comments or wishes?

[ognevny]

for me, probably throwing an error in case of no jobs is not a good idea. job should fail when it fails to get exact result

can't review the script itself so leaving it to others

[Paebbels]

[...] job should fail when it fails to get exact result

Can you please explain?

The error message contains the detailed error description. You can click the error and jump to the job and step causing the error.

There are 3 levels of errors:

• An error message is created. This is done by writing a specially formatted message into the log. It's then picked up by GitHub and listed in the annotations area.
  Besides errors, other log-level are available: warning, info
• A job itself can error out by returning a non-zero exit code
• A pipeline can error out.
  There are settings, that even with failed jobs, a pipeline stays green.

In my opinion that a pipeline must fail if there was an error.

If there are other cases for the repository, were changes are pushed but no packages are modified, it can be added and handled.

[ognevny]

[...] job should fail when it fails to get exact result

Can you please explain?

this could be green