Correct conditional logic for publishing steps of build workflow

[per1234]

Background

The "Arduino IDE" GitHub Actions workflow is used to generate several distinct types of builds:

• Tester builds of commits
• Nightly builds
• Release builds

Different operations must be performed depending on which type of build is being produced. The workflow uses dedicated jobs for publishing the nightly builds and for publishing the release builds. Those jobs are configured to run only when certain criteria are met.

One such criteria is that the merge-channel-files job ran as expected. There are four possible result types of a job, which should be handled as follows:

Result	Run dependent job?
success	Yes
failure	No
canceled	No
skipped	Yes

GitHub Actions automatically takes the desired action regarding whether the dependent job should run for the first three result types, but that is not the case for the "skipped" result. The merge-channel-files job dependency is skipped when a channel file merge is not needed and so this is not cause to cancel the build publishing.

The only way to make a dependent job run when the dependency was skipped is to add the always() expression to the job conditional. This goes too far in the other direction by causing the job to run even when the dependency failed or was canceled. So it is necessary to also add logic for each of the dependency job result types to the conditional, which makes it quite complex when combined with the logic for the other criteria of the job.

Problem

In order to reduce the amount of complexity of the conditionals of the dependent jobs, a job (merge-channel-files-complete) was interposed in the dependency chain, which was intended to act simply as a container for the logic about the merge-channel-files job result. Unfortunately it turns out that even if the direct dependency job's result was success, if any ancestor in the dependency chain was skipped, GitHub Actions still skips all dependent jobs without an always() expression in their conditional, meaning the intermediate job was pointless. This caused the build publishing jobs to be skipped under the conditions where they should have ran.

Solution

The pointless intermediate job is hereby removed, an always() expression added to the conditionals of the dependent jobs, and the full logic for how to handle each dependent job result type added there as well.

Additional Changes

Pin Python to 3.11.x minor version

97b0bc0

I found that the node-gyp installation was broken by the update to Python 3.12 in the GitHub Actions runner: nodejs/node-gyp#2869

This caused a failure of the workflow runs unrelated to the changes made by this PR:

https://github.com/per1234/arduino-ide/actions/runs/6566684071/job/17837889420#step:8:247

Traceback (most recent call last):
  File "D:\a\arduino-ide\arduino-ide\node_modules\node-gyp\gyp\gyp_main.py", line 42, in <module>
    import gyp  # noqa: E402
    ^^^^^^^^^^
  File "D:\a\arduino-ide\arduino-ide\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 9, in <module>
    import gyp.input
  File "D:\a\arduino-ide\arduino-ide\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 19, in <module>
    from distutils.version import StrictVersion
ModuleNotFoundError: No module named 'distutils'

The workaround is to pin the version of Python used for the build job in the runner environment to 3.11.

I believe the node-gyp maintainers are already working on a fix, which will be in the next release so we can likely revert this pin at some point in the future if it is preferred to only pin the major version of Python.

Restore Linux channel file uploading

dd79c63

The Linux channel file upload was disabled due to the fact that we were manually producing that build (#2020). The problem causing the need for a manually produced Linux build was fixed (#2253), but I forgot to restore the channel file upload at that time.

Minor workflow refactoring

883426d

I made a small change to the conditionals for the container/runner environment-specific steps of the build job. This is unrelated to the other work and has no functional effect, but I think it makes the workflow a little easier to understand by matching the comparison in the conditional to the matrix data.

Information for reviewers

I did some demonstration runs of the workflow (in addition to the tester build run that will be associated with the PR):

---

Triggered by workflow_dispatch event:

https://github.com/arduino/arduino-ide/actions/runs/6568764692

---

Triggered by schedule event (which causes a "nightly" build publishing):

https://github.com/per1234/arduino-ide/actions/runs/6567577721

This was performed in my fork, where I don't have the AWS credentials, so the failure of the S3 upload step in the "publish" job is expected, but you can see the rest of the workflow was successful

---

Production release:

https://github.com/per1234/arduino-ide/actions/runs/6567497724

This was performed in my fork, where I don't have the AWS credentials, so the failure of the S3 upload step in the "release" job is expected, but you can see the rest of the workflow was successful, including the creation of the GitHub Release: https://github.com/per1234/arduino-ide/releases/tag/0.0.0-rc.32

---

Additional context

Originally reported by @KurtE:

https://forum.arduino.cc/t/where-are-wifis3-examples-hiding/1178596/12

[kittaakos]

It's looking good, Per 👍

Thanks for the detailed explanation of each commit + the example workflow runs.