Two issues with putting it as an env var:
* shellcheck (via actionlint) claim it needs to be enclosed in double
quotes, but it's already in a double quoted string and I can't be
bothered dealing with yaml quoting
* the windows run doesn't seem to pick it up, maybe env vars don't work
on windows?
Whatever, we can figure out how to make it nicely over overridable later. I
just want to get a stable branch I can re-run through the week.
When I tried to include a default workers arg at the top level of the
matrix definition all it ended up doing it running a single job with "-n
2" and ignoring the whole include block, weird. Don't really understand
it yet: https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#expanding-or-adding-matrix-configurations
Falling back to putting it in an env var so at least it's only specified
once.
Drop the pylint parallelism because it's complaining that `Value
'config.cache' is unsubscriptable (unsubscriptable-object)` in many
places. Aha, that's why I've been seeing that locally and not on CI!
This installs pdf.js in a selection of CI jobs. Previously the PDF.js
tests (in qutescheme.feature) were skipped in CI because it wasn't
installed anywhere. There has been a couple of recent cases where pdf.js
started depending on javascript features that are too new for even the
most recent QtWebEngine to support. The aim of this commit is to catch
that case. This doesn't add coverage for older webengine releases.
This also incidentally updates the ace editor in these test jobs, since that is
also updated by default by the update_3rdparty script. Hopefully that
doesn't cause issues.
The reasoning for installing on each type of job:
*ubuntu jobs*: not installed - while our main test runs are on ubuntu
there is an upstream issue where many assets used by pdf.js (like icons
used in the toolbar) aren't packaged, see #7904. This causes warning
messages because assets requested via qutescheme can't be found, which
causes the tests to fail. We could a) install pdf.js from source instead
of using the ubuntu one b) ignore the warning logs c) skip this
environment and rely on tests elsewhere. I've chosen to do (c). I don't
see a huge benefit in testing pdf.js across multiple environments if we
aren't using it installed from the OS anyway. We could install from
source but currently all the Qt < 6.5 tests are failing from some other
JS error, and I think fixing that is out of scope of this issue.
*docker Qt6*: installed - the archlinux pdfjs package works fine and we are
only testing the most recent Qt versions because arch users are expected
to stay up to date.
*docker Qt5*: not installed - doesn't support JS features required by
PDF.js. I guess we could install the legacy build from source here. I'm
mostly worried about catching new breakages for this commit though
*windows*: installed - we install pdf.js from source when making a
release so it would be nice to do that in tests too.
*macos*: not installed - the tests that were catching the breakages are
end2end tests which we don't run on mac. And I think there was an
error from the :versions tests here, don't remember.
*bleeding edge*: installed - from source
pdf.js tests fail on Qt < 6.5 with `Uncaught TypeError: Cannot read
properties of null (reading 'mainContainer')`
The `TestPDFJSVersion.test_real_file` unit tests currently fails because
`version._pdfjs_version()` returns `unknown (bundled)`, not sure why. I
think this is pre-existing and it also wasn't being run on CI.
6.7 is released now, some distros are already shipping it!
This commit:
1. adds a new 6.7 requirements file (the plain 6 one has already been
updated by the bot)
2. adds a new tox env referring to the new requirements file
3. updates the mac and windows installer jobs to run with pyqt67 with the
assumption we'll be including that in our next release
4. adds two new CI environments for 6.7, one each for python 3.11 and 3.12
(3.12 only came out like 6 months ago)
5. updates a couple of references to the py37 tox env that looked like they
were missed, 3.7 support was dropped in 93c7fdd
6. updates various ubuntu containers to the latest LTS instead of the previous
related one - this is quite unrelated to this change but I thought I would
give it a go, no need to use the old one unless we are specifically testing
on it?
- linters - they use tox but probably use system libraries
- these all run in nested containers anyway, should be fully isolated
- codeql - eh, uses a third party action, check the docs if it fails
- irc - as above
Currently the unstable docker images are failing to build
(undefined symbol: _ZN5QFont11tagToStringEj, version
Qt_6. Looks like Qt has upgraded to 6.7 but pyqt6 hasn't been patched to
remove some symbols that are gone now).
But we might as well let the stable ones rebuild right?
It seems `sed -i` is not very portable. Initially we were using this
command:
sed -i '' '/.-d., .--debug.,/s/$/ default=True,/' qutebrowser/qutebrowser.py
and then that started breaking on windows, I'm not sure why, with "can't
read /.-d., .--debug.,/s/$/ default=True,/: No such file or directory".
Then we changed to:
sed -i '/.-d., .--debug.,/s/$/ default=True,/' qutebrowser/qutebrowser.py
so without the extension argument, but that broke on mac with "1:
"qutebrowser/qutebrowser.py": extra characters at the end of q command"
then we tried:
sed -i'' '/.-d., .--debug.,/s/$/ default=True,/' qutebrowser/qutebrowser.py
and that also broke on mac with the same error. On the recommendation of
stackoverflow I just changed it no not use in-place editing and do a
good old fashioned move afterwards. https://unix.stackexchange.com/questions/92895/how-can-i-achieve-portability-with-sed-i-in-place-editing
... record scratch ...
Apparently these GHA steps are being run in powershell in windows where
`mv` is implemented by `Move-Item` where you have to use -Force to
overwrite destination files.
But that's not portable. cp does happily overwrite without any
additional instruction though. So I'm doing cp instead of mv and then
removing the temp file.
Probably if this drags out anymore we should download something off of
pypi which is platform independent to handle it.
The nightly jobs have a `workflow_dispatch` action, which means you can
kick the job off on any branch. But the build steps has the branch to
build on hardcoded. I would like to be able to build windows and mac
builds without having a local build environment setup.
The docs for the checkout action says it default to the main branch,
so the scheduled actions should keep working fine. But now we'll be able
to create builds off of other branches too.
docs: https://github.com/actions/checkout#usage
ref: https://github.com/qutebrowser/qutebrowser/issues/7989
It looks like our last release builds were done with python 3.11 and
PyQt 6.5.3. I'm expecting that since PyQt6.6 is out now our next release
will be on 6.6. So lets update the CI to match.
Questions:
* what about python12? I don't think there is a benefit to updating to
that, so lets leave it.
* what about pyqt6.5? Do we care about testing that? Maybe for homebrew
users? We aren't providing new builds with an old Qt right?
last release builds: https://github.com/qutebrowser/qutebrowser/actions/runs/6578864884
ref: https://github.com/qutebrowser/qutebrowser/issues/7989
I'm not sure if we need a py3.11 pyqt6.5 variant or a py3.10 pyqt6.6
one? Those might well be combinations that people have (debian has 3.11
and 6.5 at the moment) but how much coverage do we need?
ref: https://github.com/qutebrowser/qutebrowser/issues/7989
toofar
dependabot[bot]
Florian Bruhin