Includes two small scripts: verify-bash.sh for running shellcheck, and
verify-python.sh for running pylint.
.pylint rc files is a default configuration file generated by
pylint 2.3.1, with one change (min-similarity-lines changed
from 4 to 10).
GitHub notified me, that they are dropping macOS-10.14 completely, all
users are upgraded to macOS-10.15 and the only valid value in CI jobs
will be macos-latest from now on.
I haven't seen any indication of the same happening for Windows
machines, but GitHub Actions documentation dropped all references to
windows-2016 and windows-2019 - windows-latest seems to be the only
valid value for shared runners from now on.
Ubuntu machines are left as they are (thankfully).
This way there's no need to prepend every line in build job with a path
to MSYS2-installed bash, and deal with problems related to escaping
embedded shell invocations.
Apt does not have a stable CLI interface, therefore should be avoided in
scripts. Using apt-get should be fine.
Split 'apt-get update' to a separate step. It makes it easier to
check, what mirrors and repositories are being used by CI machines.
Remove SPDX identifier - it's missing from other .yml files (I would
consider these configuration files and not source code, so not covered
by copyright).
Use the same build dependencies for static analysis build as in other
Linux jobs.
The commit makes the following changes:
- The package listing script now requires the user specify which package manager
they're using. This approach resolves the ambiguity if a system has more than
one package manager (ie: macports & brew)
- Adds packages for Fedora, RedHat/CentOS, Arch, and OpenSuse
- Eliminates unecessary code in the package manager script
(more can be eliminate at the expense of complexity)
- Made a couple minor fixes to the build script
- Tried to further "standardize" the workflows as follows:
- names are Compiler Version (Environment)
- Sorted them alphabetically in their respective YAMLs
- Minor spacing adjustment to align values (where it makes sense)
- Dropped quotes around some of the string values because I'd
rather our YAML be consistent and propper instead of changing our
YAML to suite the limitations of an editor (can a different plugin
or better parser be used?)
- Added macOS workflows for Homebrew and MacPorts, both ready to
go and tested, but with the build step just commented out
This change makes a couple changes to the CI workflow:
- Adds more compiler coverage:
- gcc to MacOS (see note below)
- 32 and 64bit gcc and clang to Windows
- With more builds, this separates them into per-OS workflow YAMLs
(laying the foundation for more build environments: BSD? DOS? ... )
- Moves all functional commands from GitHub-syntax-YAML into scripts,
which (besides eliminating repeated code), now serve a dual-purpose
of being runnable outside of GitHub.
- One script takes care of listing dependent packages for the given
runtime environment
- Another script takes care of configuring and building
These scripts can be leveraged by a nightly build & asset generator in
the future.
Note: adding GCC to MacOS is now "correct" from a build perspective,
however to keep this PR focussed on the CI workflow I have not included
the coreMIDI / AppleBlocks code-fixes here (so for now, the gcc macOS
builds will fail; we will merge the coreMIDI / AppleBlocks later
depending on how upstream wants to handle it).
log-env.sh is cross-platform (works on Linux, MacOS and Windows)
log-env.ps1 is Windows-only and requirs specifying pwsh shell, but
provides some Windows-specific information, that might be useful e.g.
for MSVC builds.
Rename it from "Compilation" to "Build", as it's shorter and takes less
space in GitHub UI.
Remove GCC8 build configuration, as it does not add value: GCC9
build provides compilation on new compiler, while other Ubuntu builds
cover compilation on default compilers.
Implements new script (count-bugs.py) for peeking inside clang static
analyzer's report and print just a summary.
If number of detected bugs goes beyond the limit, script will return
with error code 1, thus failing the CI run. The upper limit is set to
113, which is current result of static analysis in our CI environment
(local run is likely to indicate different number); upper limit will
be updated in time, as issues get fixed or new compiler (detecting more
bugs) will be introduced.
This commit includes also slight modifictaions to count-warnings.py
script, to keep the both scripts outputting in similar format.
This way it will be possible to prevent users from introducing new
warnings. As new fixes will be upstreamed, the maximum limit of
allowed warnings should be taken lower and lower, so this script
could be eventually replaced by -Werror.
So far it consists of following builds:
- GCC 9.1 (Ubuntu 18.04)
- GCC 8.3 (Ubuntu 18.04)
- GCC 7.4 (Ubuntu 18.04 default)
- GCC 5.4 (Ubuntu 16.04 default)
- Clang 10.0 (macOS 10.14 Mojave default)
- Clang 6.0 (Ubuntu 18.04)
Workflow also defines static code analysis using Clang 6 (Ubuntu 18.04),
which does not indicate results directly in PRs yet, but uploads a
static analysis report as a build artifact.
