| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Put cygwin filemode tests back under the sourcedir
Remove inheritable permissions from the sourcedir
For :reasons:, the unit tests which check file mode were built in the
tempdir.
Instead, remove inheritable permissions from the working directory
(which the GitHub VM image has set for some reaons), since they can
interfere with getting exactly the file mode you asked for.
Partially reverts 04ae1cfb7999e25f476f84572ff0ad853629346c
|
|
Use a tagged version of cygwin-install-action, rather than whatever
happens to be master at the moment.
This should help isolate meson CI from random breakage there.
|
|
Test '230 external project' uses make, but is too dumb to use the
platform conventions for shared library names in installed files
expected by shared_lib, so special case that.
|
|
|
|
|
|
|
|
Keep using v3 for Bionic because of https://github.com/mesonbuild/meson/pull/13424
|
|
|
|
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
|
|
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.
|
|
|
|
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. ;)
|
|
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...
|
|
|
|
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".
|
|
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.
|
|
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.
|
|
Which lets pytest understand unittest.subtest
|
|
|
|
Set MESON_CI_JOBNAME for all CI jobs which run project tests.
(Note that ${{ github.job }} is the literal job.id used in the yaml, not
any name given to the job with job.id.name, and so is the same for all
matrix entries, and thus not suitable for our purposes there).
|
|
|
|
* CI: Don't run cross-only test when other workflows are changed
* CI: Move Cygwin test run from Azure Pipelines to GitHub workflow
Also review installed package list, dropping detritus from 42792554, not
removed in f5ed85d7.
|
