If an annotation could not be resolved, it's classified as a "missing
import" and our configuration ignored it:
```
Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker
```
As far as mypy is concerned, this library may or may not exist, but it
doesn't have any typing information at all (may need to be installed
first).
We ignored this because of our docs/ and tools/ thirdparty dependencies,
but we really should not. It is trivial to install them, and then
enforce that this "just works".
By enforcing it, we also make sure typos get caught.
Github Actions supports this fine, but is misdetected by flake8/mypy.
Even though pylint defaults to text instead of colorized, we might as
well do the right thing here though.
This allows verifying that meson is type-safe under older versions of
Python, which it currently is. Different versions of Python sometimes
have different supported types for an API.
Verify this in CI.
(We flush output to ensure CI prints lines in the right order.)
On average, saves 20 seconds for a job that may take 1.5 or 2 minutes.
Mostly due to recompiling the same 3 wheels again and again, so that
avoids pointless CPU waste.
This has issues on Windows with msys2/cygwin, where we need to build it
ourselves since binary wheels aren't supported on PyPI. And we don't
have a rust compiler available for either one -- we may not be *able* to
do so for cygwin?
For msys2, the solution is pretty easy, just rely on the official msys2
packages for jsonschema, which handle both it and its dependencies for
us and don't require us to compile anything. Currently they still have
an older jsonschema that doesn't use rust deps at all, but that's
because the new jsonschema was released today. We'll automatically catch
up at some point.
For cygwin, there is no rust compiler in the cygwin repository, and
jsonschema there is old as the hills. I do not know if there's a good
answer here, but an adequate answer is to cap jsonschema at the version
we were testing with yesterday.
In this case, we have the secret available, and the workflow ran even
though it wasn't on branch "master" because of the pull request trigger.
Since the change hasn't landed on master, though, we do not want to
update the website. So check for pushes to master, specifically.
cache/restore and cache/save now exist, and close the issue linked in
the workflow comment. The new save action runs when invoked, rather than
as a post action.
fixes instability in precise version of tools resulting in some runners
getting a downgraded version and producing spuriously fixed/reintroduced
codeql alerts.
This is a no-op change from v2 to v3, but github complains that nodejs
is outdated if you don't. It's not obvious why this required a major
version bump...
However, half of our uses are on v1, which has a decent fix: failure to
upload artifacts constitutes a step failure.
Not much changes, really, other than it now sets PKG_CONFIG_PATH to
point to the python it just installed. This should generally not be a
problem (Meson's python module sets that anyway based on the
executable's introspection data).
lgtm.com was acquired by github. It is deprecated and on its way out,
because they've integrated the functionality itself into github. Take a
look at what its official replacement can do.
This does run as yet another Actions slot, which is already fairly
excessive, but the average runtime seems about 5 minutes so that's not
too bad...
This tests stable maintenance branches, to ensure that build directories
created with older versions of Meson continue to work without wiping,
after updating to a bugfix release.
Downgrade to LLVM-14 from LLVM-15 which is somewhat broken when using
static linking at present:
https://github.com/Homebrew/discussions/discussions/3666#discussioncomment-3681821
We can't use LLVM's lld instead of ld on macOS because we don't detect
it as an Apple linker and pass --as-needed etc to it. Even when that
is fixed and we set -lto_library etc correctly, the linker just hangs.
LLVM@14 is keg-only, so we need to add CPPFLAGS / LDFLAGS to the keg
subdir inside /usr/local
The LLVM@15 test is shared-only now and moved to the qt4 macOS job.
This was initially added in eb76ba7031 to avoid picking
it up from azure/gha images.
Looks like it is no longer set for some time now though:
https://github.com/actions/runner-images/pull/540
so should no longer be needed.
The empty string makes some meson tests fail which expect a path.
A recent msys2-runtime change now lets empty env vars through to child processes
whereas before they would get filtered out, which is why this worked before.
"MSYSTEM= python ..." no longer works because of some changes in the MSYS2 runtime
Until this is fixed in either MinGW Python or the MSYS2 runtime this should revert
things to the previous behaviour to get the CI green again.
It's a bit annoying having to *manually* disable a workflow for forks,
because the scheduled build is a waste of time and also spammy.
On the other hand, having the workflow enabled is in general a good
thing, because it is in fact desirable to test it locally in forks.
Due to https://github.com/gcovr/gcovr/pull/576 it is not possible to
`pip install gcovr` and have it work.
It is possible, but not ideal, to install the cygwin gcovr package,
which is unmaintained and built for python36 while only depending on
python39.
This is of course not a problem on the other CI jobs, where we either
install it from a distro repository that ensures it is stable and
backports patches, or simply tests that the resulting image passes tests
before baking it as a CI images update.
gcovr upstream isn't sure when they are going to release a new version
that fixes this bug. There is a new feature release scheduled "soon".
Unfortunately, checking for strings without context is exceedingly prone
to false positives, while missing anything that indirectly opens a file.
Python 3.10 has a feature to warn about this though -- and it uses a
runtime check which runs at the same time that the code fails to open
files in the broken Windows locale. Set this up automatically when
running the testsuite.
Sadly, Python's builtin feature to change the warning level, e.g. by
setting EncodingWarning to error at startup, is utterly broken if you
want to limit it to only certain modules. This is tracked in order to be
more efficiently ignored at https://bugs.python.org/issue34624 and
https://github.com/python/cpython/pull/9358
It is also very trigger happy and passing stuff around via environment
variable either messes with the testsuite, or with thirdparty programs
which are implemented in python *such as lots of gnome*, or perhaps
both.
Instead, add runtime code to meson itself, to add a hidden "feature".
In the application source code, running the 'warnings' module, you can
actually get the expected behavior that $PYTHONWARNINGS doesn't have. So
check for a magic testsuite variable every time meson starts up, and if
it does, then go ahead and initialize a warnings filter that makes
EncodingWarning fatal, but *only* when triggered via Meson and not
arbitrary subprocess scripts.
The $CI environment variable may be generally set by Github or Gitlab
actions, and is not a reliable indicator of whether we are running "CI".
It could also, for an absolutely random example that didn't *just
happen*, be Alpine Linux's attempt to enable the Meson testsuite in
their packaging, which... uses Gitlab CI.
In this case, we do want to perform normal skipping on not-found
requirements. Instead of checking for $CI, check for $MESON_CI_JOBNAME
as we already use that in all of our own CI jobs for various reasons.
This makes it easier for linux distros to package Meson without
accumulating hacks like "run the testsuite using `env -u CI`".
Now cygwin seems to have completed a migration of the default python to
3.9, so that is where the devel package is at.
Back out the changes from commit 3304a38496
and update the pip/wheel packages as appropriate.
For a long time now, this has done 3 different things, only one of which
is mypy. But they are labeled:
- LintMypy / lint
(runs pylint)
- LintMypy / custom_lint
(runs a custom script)
- LintMypy / mypy
(actually runs mypy)
This reduces the usable length of the label which isn't all that long to
begin with, is actively misleading, and even when you know what is going
on, it becomes harder to tell at a glance what failed. Change it to be
more unambiguous.
multiple versions of python are packaged by cygwin, and the default
python is auto-selected as the latest one via a Debian-like alternatives
system.
This recently broke because dblatex is built against 3.9, causing it to
be installed too and resulting in multiple (inconsistent) versions of
python being installed, and `python3` pointing to the one we don't have
devel packages for and isn't even the default version.
Fix this by pointing back to the intended python.
Eli Schwartz
Eli Schwartz
Christoph Reiter
Nirbheek Chauhan
Josh Soref
Xavier Claessens
Alex
L. E. Segovia
Carlo Cabrera
neilnaveen
mattip
Jan Tojnar
Stone Tickle
Dylan Baker
Christian Clauss