| Age | Commit message (Collapse) | Author |
|---|
|
The macos 13 runner has been removed, and OpenSSL 1.0 fails to build, so
let's just retire this test.
|
|
|
|
The workaround in commit 2f146775e ("Work around the mising RECORD
file with homebrew pip.", 2025-05-04) is brittle and has broken
again. Do not bother updating setuptool and pip at all, they should be
relatively up to date on homebrew.
Suggested-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
Using Homebrew Clang leads to failures when testing objfw. We probably
want to ensure we use Apple Clang here given the workflow job name, in
any case.
|
|
|
|
|
|
Keep using v3 for Bionic because of https://github.com/mesonbuild/meson/pull/13424
|
|
|
|
|
|
|
|
There are some additional packages that seem to be needed on Apple based
Silicon.
|
|
homebrew installs to /usr/local on Intel based macs, but has moved to
/opt/homebrew for those using Apple Silicon.
|
|
Qt4 doesn't seem to work on Apple Silicon because OpenSSL 1.0 (a
requirement for Qt4) doesn't build on it correctly, trying to use X86
assembly.
|
|
Followup to commit 5c479d7a13a518c18ccb4dc3b6bdd7bfc2a9bdb5.
In this case, PEP 668 was created to allow a thing that Debian wanted,
which is for `pip install foobar` to not break the system python. This
despite the fact that the system python is fine, unless you use sudo pip
which is discouraged for separate reasons, and it is in fact quite
natural to install additional packages to the user site-packages.
It isn't even the job of the operating system to decide whether the user
site-packages is broken, whether the operating system gets the answer
correct or not -- it is the job of the operating system to decide
whether the operating system is broken, and that can be solved by e.g.
enforcing a shebang policy for distribution-packaged software, which
distros like Fedora do, and mandating not only that python shebangs do
not contain `/usr/bin/env`, but that they *do* contain -s.
Anyway, this entire kerfuffle is mostly just a bit of pointless
interactive churn, but it bites pretty hard for our use case, which is a
container image, so instead of failing to run because of theoretical
conflicts with the base system (we specifically need base system
integration...) we fail to run because 5 minutes into pulling homebrew
updates at the very beginning, pip refuses point-blank to work. I
especially do not know why it is the job of the operating system to
throw errors intended for interactive users at people designing system
integration containers who cannot "break" the system python anyway as it
is thrown away after every use.
Fix this by doing what homebrew should have done from the beginning, and
opting containers out of this questionable feature entirely.
|
|
The following workflows have been updated so that they are
triggered when the any of the test harnesses are updated:
macos,
os-comp,
msys2
Previously only changes to `run_unittests.py` caused these
workflows to be executed.
|
|
Commit 191449f60879a622661b96600babaec67477d5bb has numerous issues, and
being completely invalid yml syntax was just the tip of the iceberg.
In this case, it fails the github schema, which requires that env be
adjunct to a job or step definition, rather than its own thing. It did
not even make sense in context, since the purpose of the variable is to
modify brew.
Fixes: #12644
Fixes: #12681
|
|
|
|
We're getting errors that we don't care about on the CI like:
```
==> Pouring node@18--18.19.0.monterey.bottle.tar.gz
The formula built, but is not symlinked into /usr/local
Error: The `brew link` step did not complete successfully
Could not symlink lib/node_modules/npm/docs/content/commands/npm-sbom.md
Target /usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md
already exists. You may want to remove it:
rm '/usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md'
```
We don't care about node, the only reason it's getting updated is
because it's already installed on the image and brew is auto-updating
it. So let's disable auto-update.
|
|
|
|
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
|
|
|
|
The pypi package was suddenly removed. Not the most
confidence-inspiring deprecation/migration:
https://about.codecov.io/blog/message-regarding-the-pypi-package/
|
|
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).
|
|
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.
|
|
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.
|
|
Need to link the qt4 install so it's in PATH.
Also need to use a symlink to fix breakage in the Tap.
|
|
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>
|
|
The `-framework Foundation -framework CoreFoundation` ended up
de-duplicated by OrderedSet into `-framework Foundation CoreFoundation`.
|
|
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`".
|
|
Which lets pytest understand unittest.subtest
|
|
|
|
Previously the meson test case would only test boost-python on linux.
With the #7909 it is now possible to use boost-python on macOS/homebrew.
This enables the boost-python test on both linux and macOS.
It also uses python.extension_module() instead of shared_library to make the
python extension module.
|
|
|
|
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).
|
|
|
|
|
|
|
|
We're already covering most of the actions through the generic macos
actions, but we should keep the qt4 action.
|
|
|
|
|
