| Age | Commit message (Collapse) | Author |
|---|
|
The former has rust dependencies, which lead to max capping on Cygwin
since there is no rust compiler there. But it turns out there are other
disadvantages of jsonschema:
- it involves installing 5 wheels, instead of just 1
- it is much slower
To give some perspective to the latter issue, this is what it looks like
when I test with jsonschema:
```
===== 1 passed, 509 deselected in 3.07s =====
Total time: 3.341 seconds
```
And here's what it looks like when I test with fastjsonschema:
```
===== 1 passed, 509 deselected, 1 warning in 0.28s =====
Total time: 0.550 seconds
```
I cannot think of a good reason to use the former. Although in order to
work on old CI images, we'll support it as a fallback mechanism
|
|
|
|
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 reverts commit e945f35cd72402d0d204ff10870e2a95c59b6192.
With MSYS2 udpating to Python 3.11, this should no longer be needed.
See https://github.com/msys2/MINGW-packages/issues/17415#issuecomment-1606085553
|
|
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.
|
|
|
|
The pypi package was suddenly removed. Not the most
confidence-inspiring deprecation/migration:
https://about.codecov.io/blog/message-regarding-the-pypi-package/
|
|
This reverts commit 0022e1863d8d9769378ebfb56695bdbf55f118b9.
The bug is long since both fixed and *released*.
|
|
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.
|
|
Like every single other command in the entire workflow, and for the same
reasons. ;)
|
|
Found by https://www.check-spelling.dev/
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
Found by https://www.check-spelling.dev/
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
Silence a couple of framework tests that need to be skipped since we
don't install their dependencies for pypy3.
|
|
fixes instability in precise version of tools resulting in some runners
getting a downgraded version and producing spuriously fixed/reintroduced
codeql alerts.
|
|
Signed-off-by: Alex <aleksandrosansan@gmail.com>
|
|
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.
|
|
This is a no-op change, but github complains that nodejs is outdated if
you don't. It's not obvious why this required a major version bump...
|
|
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...
|
|
The default actions one is broken in two ways, and additionally
overwrote homebrew's symlinks to begin with.
|
|
|
|
This makes sure we don't end up picking up an older version of LLVM that
does not work.
|
|
Fixed in Homebrew/homebrew-core#112154.
This reverts commit c20fb659f600149c08d635fc3750f03632164b9b.
|
|
There hasn't been any progress on this upstream lately, so
try what we use in MSYS2 CI right now
|
|
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 eb76ba7031f053a3c1 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.
|
|
separator behaviour"
This reverts commit 3fd2459a748cc9eed4be73132b002400da81cb0a.
The underlying issue has been fixed and deployed:
https://github.com/msys2-contrib/cpython-mingw/pull/107
|
|
"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.
|
|
Need to link the qt4 install so it's in PATH.
Also need to use a symlink to fix breakage in the Tap.
|
|
We should have full coverage now, so make sure we don't regress in the
future.
|
|
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
- Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
[Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
Signed-off-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
|
|
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.
|
|
|
|
The `-framework Foundation -framework CoreFoundation` ended up
de-duplicated by OrderedSet into `-framework Foundation CoreFoundation`.
|
|
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 3304a38496a52052ae9d58ed2459c7deb18ca703
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.
|
|
And the outdated pin means some error messages that are a lot better in
newer versions aren't available.
|
|
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.
|
